[jboss-user] [JBoss Cache: Core Edition] - Rolled back transactions sometimes failing to release locks

nathanmesser do-not-reply at jboss.com
Tue Feb 10 06:46:16 EST 2009


We have a problem with JBoss Cache 3.0.2 (also present on 3.0.0) using MVCC locking, on Weblogic 10.3, running in a single instance, whereby a transaction can rollback due to a timeout but not release the locks it's holding.

In normal use this happens fairly rarely, but often enough to be worrying, as the only way to release the lock is to restart the cache. 

It's also not as simple as a transaction rolled back by timeout will always fail to release all it's locks, as normally it works fine.

By fluke I've found out that if I reduce my JTA and lock timouts, and turn on trace logging on the TxInterceptor, then when I start up our app (which loads various sets of data into the cache, in seperate transactions) I can cause this to happen.

I've included the error we get (sometime after GlobalTransaction:28 has rolled back), and our jboss cache configuration file.

I've also got the jboss cache trace log for org.jboss.cache.inteceptors.TxInterceptor and org.jboss.cache.lock on GlobalTransaction:28, but that's quite large, is there a better way of making that available to jboss cache developers than trying to paste the log into a forum message?

1) Are there any other logs that would be useful?

2) I recall when I saw this before Christmas, when I assumed it was related to replication, Manik mentioned that weblogic 10.3 should now have a fixed transaction manager implementation. Does this look like it refutes that, or is this another problem?

3) Any ideas for a workaround? We're planning to go live in a few weeks, and this is quite worrying.

<jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.0">

    <!--
        isolationLevel : SERIALIZABLE - (not supported in mvcc) REPEATABLE_READ (default)
        READ_COMMITTED READ_UNCOMMITTED (not supported in mvcc) NONE lockAcquisitionTimeout: max
        number of milliseconds to wait for a lock acquisition nodeLockingScheme : mvcc (default)
        optimistic pessimistic
    -->
    

    <!-- Configure the TransactionManager -->
    

   
         


Caused by: org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/Branch/1133] after [2000] milliseconds for requestor [GlobalTransaction::38]! Lock held by [GlobalTransaction::28]
	at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:170)
	at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:248)
	at org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutDataMapCommand(MVCCLockingInterceptor.java:94)
	at org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutDataMapCommand(PrePostProcessingCommandInterceptor.java:70)
	at org.jboss.cache.commands.write.PutDataMapCommand.acceptVisitor(PutDataMapCommand.java:104)
	at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
	at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
	at org.jboss.cache.commands.AbstractVisitor.visitPutDataMapCommand(AbstractVisitor.java:60)
	at org.jboss.cache.commands.write.PutDataMapCommand.acceptVisitor(PutDataMapCommand.java:104)
	at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
	at org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:284)
	at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:271)
	at org.jboss.cache.commands.AbstractVisitor.visitPutDataMapCommand(AbstractVisitor.java:60)
	at org.jboss.cache.commands.write.PutDataMapCommand.acceptVisitor(PutDataMapCommand.java:104)
	at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
	at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
	at org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutDataMapCommand(InvocationContextInterceptor.java:64)
	at org.jboss.cache.commands.write.PutDataMapCommand.acceptVisitor(PutDataMapCommand.java:104)
	at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:265)
	at org.jboss.cache.invocation.CacheInvocationDelegate.invokePut(CacheInvocationDelegate.java:672)
	at org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:518)
	at org.jboss.cache.invocation.NodeInvocationDelegate.addChild(NodeInvocationDelegate.java:327)
	at uk.co.cdl.utility.cache.jbosscache.CDLJBossReplicationCacheAdapter.getSpecificNode(CDLJBossReplicationCacheAdapter.java:186)
	at uk.co.cdl.utility.cache.jbosscache.CDLJBossReplicationCacheAdapter.put(CDLJBossReplicationCacheAdapter.java:136)
	... 16 more



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208496#4208496

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208496



More information about the jboss-user mailing list