concurrency & transactions question

[Konstantin Sobolev]

Hi

I'm looking for a way to use transactional cache together with transactional DB, and I'm intersted in how to resolve the following race condition.

Suppose we have 2 threads, T1 and T2, some key K and corresponding value V, which reflects DB data.

1. T1.tx.begin(); T1 is about to change state in DB
2. T2 (no tx context): cache.get(K) --> miss
3. T2: V1 = DB.read; (reads 'old' state)
4. T1: DB.write(V2)
5. T1: cache.put(K,V2)
6. T1: tx.commit()
7. T2: cache.put(K,V1)

Result: DB contains V2, cache contains V1

Does Infinispan provide anything to fix it? (Explicit locking?)

Thanks

[Manik Surtani]

Are you using this for a JPA application?  If so, you probably want to use Hibernate since Hibernate's 2nd-level-cache integration with Infinispan handles this.

[Konstantin Sobolev]

No, I'm using my own persistence layer.

Could you give me any details on how Hibernate+Infinispan handles this? Versioning?

It actually looks very similar to write-skews described in JBossCache docs:

http://docs.jboss.org/jbosscache/3.2.1.GA/userguide_en/html/transactions.html

Section 11.1.1.2.2. Concurrent Writers and Write-Skews

[Johan Andries]

You could probably start a transaction in T2 (which you commit after the put of V1), and do

cache.getAdvancedCache().lock(K);

before you do the c.get(K) operation. That way the put of V2 in T1 (or at least the commit if you do not configure eager locking) will block until the transaction of T2 has finished. See SyncReplLockingTest for an example.

Important remark voor 4.1 RC2: this explicit locking does not seem to work in distributed mode, only local and replicated mode. I should probably modify SyncReplLockingTest to run in distributed mode and submit it as a defect.

Johan.

[Manik Surtani]

You can have a look at the source code of the Infinispan 2nd level cache adapter in the Hibernate src tree.  It makes use of putForExternalRead(), but also makes use of its own versioning. 

To simplify this further there is a JIRA on the roadmap to make internal entry versioning explicit and externally accessible.

[Manik Surtani]

Important remark voor 4.1 RC2: this explicit locking does not seem to work in distributed mode, only local and replicated mode. I should probably modify SyncReplLockingTest to run in distributed mode and submit it as a defect.

Yes, please do clone and update the test, and if it still is a defect please report it using JIRA.

[Johan Andries]

Jira items created:

Explicit locking has no effect in distributed mode

The useEagerLocking config setting has no effect in distributed mode

[Konstantin Sobolev]

I've reviewed it, and as I understand it most of the logic is in the http://fisheye.jboss.org/browse/Hibernate/core/trunk/cache-infinispan/src/main/java/org/hibernate/cache/infinispan/access/PutFromLoadValidator.java?r=HEAD

My scenario would be translated to:

1. T1: tx.begin()
2.     T2: cache.get(K) --> miss; causes PutFromLoadValidator.registerPendingPut(K)
3.     T2: V1 = DB.read();    old state
4. T1: DB.write(V2)
5. T1: cache.invalidate(K) => PutFromLoadValidator.invalidateKey(K); invalidates T2's pending put
6. T1: tx.commit()
7.     T2: attempt to putFromLoad, but PutFromLoadValidator.acquirePutFromLoadLock returns false

result: cache.get(K) == null

Could you confirm I got it right?

[Manik Surtani]

Yep.

[Konstantin Sobolev]

Thanks. How about this race then, is it possible?

1. T1: tx.begin()
2. T1: DB.write(V2)
3. T1: cache.invalidate(K)
4.     T2: cache.get(K) - miss
5.     T2: V1 = DB.read();    old state (isolation!)
6.     T2: cache.putFromLoad(K, V1)
7. T1: tx.commit()

IMHO invalidate() must block not only previous pending puts, but all future puts as well, untill current tx commits.

In the other words it must ensure that cache.get(K) is null right after tx has ended.

[Manik Surtani]

Yes, it will hold on to the write lock until the tx completes.