a.Optimistic Offline Lock Pattern

  1. Motivation
    1. Prevents conflicts between concurrent business transactions by detecting a conflict and rolling back the transaction.
  2. Summary
    1. An Optimistic Offline Lock is obtained by validating that, in the time since a session loaded a record, another session hasn't altered it.
    2. It can be acquired at any time but is valid only during the system transaction in which it is obtained. 
    3. Optimistic Offline Lock assumes that the chance of conflict is low.

  3. When to Use
    1. Optimistic concurrency management is appropriate when the chance of conflict between any two business transactions is low. If conflicts are likely it's not user friendly to announce one only when the user has finished his work and is ready to commit.
    2. As optimistic locking is much easier to implement and not prone to the same defects and runtime errors as a Pessimistic Offline Lock, consider using it as the default approach to business transaction conflict management in any system you build.
  4. Types/Variants 
    1. TODO
  5. Implementation
    1. The most common implementation is to associate a version number with each record in your system.
    2. When a record is loaded that number is maintained by the session along with all other session state. Getting the Optimistic Offline Lock is a matter of comparing the version stored in your session data to the current version in the record data. 
    3. Once the verification succeeds, all changes, including an increment of the version, can be committed. 
    4. The version increment is what prevents inconsistent record data, as a session with an old version can't acquire the lock.
  6. References
    1. http://martinfowler.com/eaaCatalog/pessimisticOfflineLock.html