4 Replies Latest reply on Jul 18, 2005 6:52 AM by skipy

    Different behaviour of TreeCache when using DummyTM and Obje

    skipy

      I have a problem with TreeCache on the following use case:

      1. Starting transaction on two cluster nodes
      2. Putting the same value(s) into cache on both nodes
      3. Trying to commit on one node - having exception (that should be so)

      So, the problem is the following.

      * When I use DummyTransactionManager, inserted values are removed from the cache because of exception. Thus, commit on the second node is successfull.
      * When I use Transaction managed from JOTM (2.0.10), inserted values are NOT removed from the cache. Thus, commit on the second node fails.

      How I use JOTM:

      1. I use TM as a local, not bound to JNDI, I've create singleton TMService holder.
      2. I've create TransactionManagerLookup implementation, which return TM from singleton TMService holder. This is required for TreeCache, as far as I understand. I've place TransactionManagerLookupClass attribute into config file with my implementation class' name as a value.
      3. I use singleton TMService holder to obtain UserTransaction from TMService. I use this UserTransaction to work with transactions.

      If I miss some steps on TreeCache registration with transaction manager?

      Regards,
      Eugene aka Skipy

        • 1. Re: Different behaviour of TreeCache when using DummyTM and

          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

            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

              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

                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