Print Page | Close Window

Merge of Data following RestoreCache

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2009
Forum Discription: For .NET 3.5
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1790
Printed Date: 28-Mar-2024 at 5:10am


Topic: Merge of Data following RestoreCache
Posted By: RyanBritton
Subject: Merge of Data following RestoreCache
Date 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



Replies:
Posted By: GregD
Date 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.





Posted By: RyanBritton
Date 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?


Posted By: GregD
Date 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.


Posted By: RyanBritton
Date 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.



Print Page | Close Window