New Posts New Posts RSS Feed: Merge of Data following RestoreCache
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Forum LockedMerge of Data following RestoreCache

 Post Reply Post Reply
Author
RyanBritton View Drop Down
Newbie
Newbie
Avatar

Joined: 28-Oct-2009
Location: South Africa
Posts: 10
Post Options Post Options   Quote RyanBritton Quote  Post ReplyReply Direct Link To This Post Topic: Merge of Data following RestoreCache
    Posted: 06-May-2010 at 6:03am
Hi guys,

I have a question regarding the reconstitution of data from a file:

Once the file/cache has been loaded into memory there is a good chance that some of this data may be stale. Is there a process whereby the data in the cache can be "refreshed" against the BOS or a way to implement this manually? Obviously, if ~all~ the data is refreshed from the main database it defeats the purpose of the cache.

What am I missing?

Ryan
Back to Top
GregD View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 374
Post Options Post Options   Quote GregD Quote  Post ReplyReply Direct Link To This Post Posted: 06-May-2010 at 7:08am
Many discontinuities between the data in the cache and the data in the database can be dealt with satisfactorily simply by handling concurrency conflicts that occur at the time of saving. You can also selectively refresh particularly volatile data at points in your application where that data is in critical use. For example, in an online ticket sales app you might refresh data about available seats when the user activates the form that displays those and facilitates sales to the customer. Or you might simply provide a button for the sales clerk to obtain current information, on demand, about the available seats.

A more sophisticated scheme would involve doing change tracking in the database itself. For example, you could create triggers on each of your tables which would write a record to an audit table whenever a record was added, modified, or deleted. This record would indicate the table where the change occurred, the nature of the change, and the primary key of the changed record. Then you could base an entity in your model on the audit table, and refresh the collection of audit entities at some interval of your choosing to obtain information about changes in the database. Then you could decide -- quite selectively -- whether and what to refresh from the database.



Back to Top
RyanBritton View Drop Down
Newbie
Newbie
Avatar

Joined: 28-Oct-2009
Location: South Africa
Posts: 10
Post Options Post Options   Quote RyanBritton Quote  Post ReplyReply Direct Link To This Post Posted: 06-May-2010 at 7:27am
Thank you for the speedy reply - that makes sense.
 
It would be neater if the cache/BOS data resolution could be automatically handled on-request based on the timestamped column that I am using for concurrency (as per DevForce documentation), don't you think? Is there no way that this might be implemented (given your knowledge of the DevForce stack)?
 
Is there a best practice for handling concurrency conflicts in a standard manner (ie: without building screens for every object type in the system) in the documentation (or samples) that I can look at?
Back to Top
GregD View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 374
Post Options Post Options   Quote GregD Quote  Post ReplyReply Direct Link To This Post Posted: 06-May-2010 at 8:29am
Originally posted by RyanBritton

It would be neater if the cache/BOS data resolution could be automatically handled on-request based on the timestamped column that I am using for concurrency (as per DevForce documentation), don't you think? Is there no way that this might be implemented (given your knowledge of the DevForce stack)?


I'm not sure how we would keep that from becoming a major performance ball-and-chain.  The only way we could know if the timestamped column's value changed for a given entity would be to query the database and compare the value found there with the local one. That times every entity in the cache, at frequent intervals.


Originally posted by RyanBritton

Is there a best practice for handling concurrency conflicts in a standard manner (ie: without building screens for every object type in the system) in the documentation (or samples) that I can look at?


See the folder 040_BusObjPersistence\ConcurrencyConflicts in the LearningResources for some ideas.
Back to Top
RyanBritton View Drop Down
Newbie
Newbie
Avatar

Joined: 28-Oct-2009
Location: South Africa
Posts: 10
Post Options Post Options   Quote RyanBritton Quote  Post ReplyReply Direct Link To This Post Posted: 06-May-2010 at 11:27pm

1. If the refresh was user initiated and the mechanism for checking for updates involved sending only the key and concurrency-marker information to the BOS (which processed the info and returned only records which had chaneged) this might reprasent a viable and performant mechanism? Or am I kidding myself?

2. Thanks for the pointer re: concurrency handling - much appreciated.
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down