2 Replies Latest reply on Apr 22, 2011 7:06 AM by Mircea Markus

    A misuse or a regression in the JTA Support?

    Nicolas Filotto Novice

      Hi all,


      I'm currently facing a weird issue, I don't know if it is a misuse on my side or a simple regression between ISPN 4.2.1.FINAL and 5.0.0.BETA(1 and 2) but at first glance it looks like a regression. In ISPN, we have an auto-enlistment mechanism that wraps the ISPN cache instances into a TransactionXaAdapter which implements the inerface XAResource, the issue that I get, occurs when we have 2 cache instances that we would like to enroll into the same Global Tx. Since the method isSameRM returns true, the TM enlists only one cache instead of 2 which obvisouly makes ISPN forget to commit the changes on the second cache and even worse, forget to release the locks which makes the 2nd cache unuseable since we get "TimeoutException: Unable to acquire lock after".. anytime we try to modify a key that has not been released.


      See below the corresponding test case:


         public void testUpdate() throws Exception
            Cache<String, String> cache1 = manager.getCache("cache1");
            Cache<String, String> cache2 = manager.getCache("cache2");
            TransactionManager tm = cache1.getAdvancedCache().getTransactionManager();
            cache1.put("a", "value1");
            cache2.put("b", "value2");
            assertEquals("value1", cache1.get("a"));
            assertEquals("value2", cache2.get("b"));


      If you use a TM other than the DummyTransactionManager, the test case will fail with ISPN 5.0.0 and will pass with 4.2.1.FINAL. As explained above the main difference is the method isSameRM that returns true in ISPN 5.0.0 since the method LocalTransaction.equals(Object) has changed.


      Find the full unit test using Arjuna as attached file


      Thx in advance for helping,