-
1. Re: Different behaviour of TreeCache when using DummyTM and
ben.wang Jul 15, 2005 11:31 AM (in response to skipy)Skipy,
Can you turn on the logging to see if the transaction is rolled back in the JOTM case.
BTW, if it works, would you like to contribute the Lookup class for JOTM?
-Ben -
2. Re: Different behaviour of TreeCache when using DummyTM and
skipy Jul 18, 2005 4:20 AM (in response to skipy)Bela, here is the complete log:
12:12:56,436 [WARN] org.jboss.cache.interceptors.ReplicationInterceptor: runPreparePhase() failed. Transaction is marked as rolled back org.jboss.cache.lock.TimeoutException: write lock for /named/brokersreport could not be acquired after 5000 ms. Locks: Read lock owners: [] Write lock owner: <10.1.2.150:2995>:1 (caller=<10.1.2.150:2906>:1, lock info: write owner=<10.1.2.150:2995>:1 (activeReaders=0, activeWriter=Thread[AWT-EventQueue-0,6,main], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)) at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:174) at org.jboss.cache.Node.acquireWriteLock(Node.java:516) at org.jboss.cache.Node.acquire(Node.java:473) at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:242) at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:153) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:41) at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:41) at org.jboss.cache.interceptors.ReplicationInterceptor.handlePrepare(ReplicationInterceptor.java:299) at org.jboss.cache.interceptors.ReplicationInterceptor.replicate(ReplicationInterceptor.java:179) at org.jboss.cache.TreeCache._replicate(TreeCache.java:2713) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:286) at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:236) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:618) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:515) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:734) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:566) at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:703) at java.lang.Thread.run(Thread.java:534) *** Exception while commiting: org.jboss.util.NestedRuntimeException: ; - nested throwable: (org.jboss.cache.lock.TimeoutException: write lock for /named/brokersreport could not be acquired after 5000 ms. Locks: Read lock owners: [] Write lock owner: <10.1.2.150:2995>:1 (caller=<10.1.2.150:2906>:1, lock info: write owner=<10.1.2.150:2995>:1 (activeReaders=0, activeWriter=Thread[AWT-EventQueue-0,6,main], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)))
As far as I understand from this log, transaction is marked as rolled back, but rollback is not performed. That's strange for me.
Regards,
Eugene aka Skipy -
3. Re: Different behaviour of TreeCache when using DummyTM and
belaban Jul 18, 2005 4:35 AM (in response to skipy)I don't know what you want to do, can you take a look at
org.jboss.cache.replicated.SyncReplTxTest and method testSyncReplWithModficationsOnBothCachesSameData() ?
This creates 2 caches, starts a TX (on each instance), modifies the same data on both instances, then tries to commit. The TX will roll back, because this simulates local TXs modifying each instance, then trying to commit.
This is *NOT* a global transaction (a la Xid). -
4. Re: Different behaviour of TreeCache when using DummyTM and
skipy Jul 18, 2005 6:52 AM (in response to skipy)Hi, Bela!
Thank you for your answer. I found where the problem is by looking on the example you've pointed me onto. You use TransactionManager.begin() method to start transaction and Transaction.commit()/Transaction.rollback() to commit/rollback transaction. Previously I've used UserTransaction for all these operation. Thus, when I've changed my code and start to use your approach, rollback become successfull and commit from the second node also become successfull. Thank you!
Regards,
Eugene aka Skipy