I saw there are 2 supported isolation levels of transactions in Infinispan: READ_COMMITTED and RR.
However I am not able to see the functional difference between the two. Both using optimistic locking and pessimistic locking. The documentation says locks are acquired only when a put operation is done. Can you give me a test case where we can see the functional difference between the two. Also please explain conceptually what it means in infinispan domain. Because what would make sense for RR is taking a lock on read also.
Consider the following case -
read and check if a key exists
if not make a custom object and put
//Do some thing here - other cache operations.
If we have 2 such transactions running simultanously even in RR level the second tx will over write the key - even with PESSIMISTIC locks which is not good! Am I mistaken somewhere?
The difference is simple:
With read committed, if between two consecutive read calls on the same key, the key has been updated by another transaction, the second read will return the new updated value:
1. Thread1: tx.begin()
2. Thread1: cache.get(k) returns v
3. Thread2: tx.begin()
4. Thread2: cache.get(k) returns v
5. Thread2: cache.put(k, v2)
6. Thread2: tx.commit()
7. Thread1: cache.get(k) returns v2!
With repeteable read, step 7 will still return v. So, the idea is that if you retrieve the same key multiple times within a transaction, you should use repeteable read.
Btw, as always, we have tests in the Infinispan code base that show this in action: