• New Feature
  • Status: Open
  • 3 Minor
  • Resolution:
  • DSO:L1
  • prodmgmt
  • Reporter:
  • March 08, 2007
  • 1
  • Watchers: 1
  • March 19, 2010

Description

Hibernate second level cache needs to lock cache entries before they can be made permanent. This locking should support timeout so that hibernate transaction fails if entries can not be locked with in certain time frame.

Currently TC does not have a mechanism to acquire the lock with timeout .

Comments

Saravanan Subbiah 2007-03-08

Reentrant lock supports tryLock with a timeout. Maybe that can be used for this ?

njain 2007-03-08

Since each entry has its own lock, either a ReentrantLock should be created for each entry or use single ReentrantLock and create multiple Condition Object (one for each cache entry). In either case there would be to many lock/condition objects. This may not be efficient.

Sreenivasan Iyer 2007-03-08

Is there a feature on the road-map (based on prior discussions) to expose lock-timeouts and provide a callback to allow the application developer to do something useful in the context of their application ? (e.g. in case of this use-case, it might be to rollback the transaction, but someone else might decide to implement some retry logic in their application and/or take the L1 out of rotation in case of encountering lock-timeout exceptions repeatedly). I recall discussing this in depth - but am not sure if it got deprioritized/subsumed under something larger.

Sreenivasan Iyer 2007-03-08

Related JIRAs: https://jira.terracotta.org/jira/browse/PM-43 https://jira.terracotta.org/jira/browse/RMP-82 https://jira.terracotta.org/jira/browse/DEV-309

Saravanan Subbiah 2007-03-08

Nitin,

Reentrant locks internally uses DSO locks and hence the support for tryLock is already there at the SPI level. But it will be much cleaner to use something like Reetrantlocks rather than tying down to the SPI.

The solution for the problem you described is to have a table of Reentrant locks (say n) that are reused as needed to lock the rows that are currently updated. This number n could be set to correspond to the number of simultaneous access to the cache (threads). so the number of reentrant locks needed is only a factor of the number of threads we want to give simultaneous access to and NOT a factor of the number of entries in the cache table. Something similar to this done in Sleepycat.

Saravanan