Concur_optimistic, concur_pessimistic

Question

Hi,
     I am trying to understand concurrency controls under Tangosol Coherence.
     In the database context, pessimistic locking is typically implemented as a persistent read lock on the row in question at read time, which is subsequently escalated to a write lock upon updation.
     Optimistic locking does not employ persistent read locks at read time ; however, some kind of version checks are performed at write time(this is typically application-specific).
     Does Coherence work the same way? I understand CONCUR_PESSIMISTIC locks the underlying cache entry upon read. What about CONCUR_OPTIMISTIC? Is there some kind of version check done in this case?
     Thanks,
     CR

Answer 1

<blockquote>concur_optimistic under REPEATABLE_READ and SERIALIZABLE behaves similar to Oracle's implementation of the SERIALIZABLE isolation level in that an exception is thrown if the underlying row/cache entry has been updated by a difference transaction AFTER the row/cache entry was read by the current transaction.</blockquote>
     Yes. That is exactly the intent -- to "validate" the transaction during the prepare processing to determine if the constraints (i.e. versions haven't changed) still hold true.
     Coherence even allows you to "custom validate" so you can automatically resolve certain kinds of changes that you don't want to cause a transaction rollback (i.e. you can give permission for the transaction to commit, even if some of the data was changed by another transaction, by fixing up the data yourself in a "transaction validator" -- but this is a very advanced feature primarily used for very long running transactions).
     Peace,
     Cameron Purdy
     Tangosol, Inc.
     Coherence: Shared Memories for J2EE Clusters