Ali, here is what the Developer's Guide says about "optimistic concurrency":

 

Many applications must guard against the possibility that two different users will unknowingly edit and save the same entity simultaneously. Without some kind of checking, the last person to save wins. If I sell a particular item and you sell the same item, we will have sold the same item twice although the database will show only that you sold it.
I could have put a database lock on the item record, thus preventing you from reading and editing it. Such “pessimistic locking” harms performance and leads to troubling lock-out scenarios. Neither DevForce nor the Entity Framework supports such a physical locking scheme.
The Entity Framework relies on “optimistic concurrency” techniques to detect and resolve concurrent access conflicts. Optimistic concurrency assumes that two users rarely wrestle over the same record and therefore allows all users to access records freely. If two users, such as you and I, try to update the same record, it detects the conflict and terminates the second save; it informs the second client be raising a concurrency exception.
The Entity Framework implements optimistic concurrency by comparing the value of a concurrency column in the pending record with the value of that column in the stored record. If the values are the same, the pending record can be saved. If the values are different, the pending record is out of sync with the stored record; the framework assumes a concurrency conflict and throws the exception.
This technique works so long as the concurrency value is changed after each successful save. Who is responsible for that change? The Entity Framework says that you are.
You are fortunate if the database table has an update trigger that can do it. Otherwise, you have to write the code that updates the concurrency column and you have to remember to call it at the right moment.
DevForce can handle the concurrency column update for you. In the DevForce Object Mapper you declare the concurrency column (or columns) and pick a method from a list of concurrency column update methods. DevForce will call that method at the appropriate time. Yes, you can extend the list with a custom method.

Thanks for pointing out that DevForce can automate the optimistice concurrrency count/timestamp and the FIRST (not last as per your reply, please correct me if I wrong) update wins and all other would get exception on which the developer can refresh her cache.

 

This was not my question however, I need you to tell us how does DevForce help with keeping all caches up-to-date (called cache concurrency).

 

Say I have two sales reps and both need to issue sales orders on the same product and takes them few minutes to complete the sales orders. They need to look at the product quantity available in stock and sell accourdingly. I am asking if there is a simpler way than Object Lifecycle Events to notify the sales rep that is still editing a sales order that the quantity in stock has changes so she can tell the customer to reduce his order.

 

This was a very simple but typical example. In general imagine we develop a stock market game (yes it is a game :) and players need to know at near realtime (not at commit time) what the state of the game is.

 

Any help from DevForce would help all of us I am sure.

 

Thanks.

 

Ali

Thanks for the correction *Concurrency* --> Coherency :)

Peace,

Ali