[jboss-dev-forums] [Design of JBossCache] - Node locking and transactions

I'm kicking off this discussion in response to JBCACHE-923 and Jacek Halat's post on node locking algorithms on http://jboss.org/index.html?module=bb&op=viewtopic&p=4084417#4084417. Most of the problems reported centre around a premise that a transaction manager may attempt to clean up timed out transactions (by rolling them back) in a separate thread. Now this can lead to problems with the existing pessimistic lock interceptor since locks are obtained and held on Thread (in the non-tx case) or GlobalTransaction (in the tx case). This almost implies that only a single thread may at any time use a GlobalTransaction, and we do see problems when two threads (one being a cleanup rollback thread) try and use the same gtx at the same time. 1. App thread starts tx, writes to /a 2. App thread attempts to write to /a again 3. Tx times out, TM attempts a rollback in a separate thread 4. The write lock on /a is owned by the gtx, which means the rollback thread is allowed to restore the state of /a and the app thread is *also* allowed to change the state of /a in (2). In addition to inconsistent state, this can also lead to stale locks. Now a lot of these issues come from the fact that there is an assumption that the TM will not attempt a rollback in a different thread, simultaeous to the app thread working in the transaction. A proper fix would involve rearchitecting how locking is handled in the cache (and this is underway) but as a workaround, does it make sense to serialize access to the cache on a per-gtx basis? 1. Tx interceptor to maintain a list of 'currently working' gtxs. 2. Only allow one thread at a time up the interceptor chain per gtx, causing other threads to block. This should effectively prevent such collissions. Keep in mind I haven't spent much time thinking about this solution yet - so by all means do tear it apart! :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085078#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...