3 Replies Latest reply on Jul 7, 2010 11:31 AM by Manik Surtani

    POJO rollback problem

    Bryan Grunow Newbie

      I'm running some old JUnits that I thought used to work sometime back but now the following test fails.

       

      Basically, we're adding a pojo to the cache under a transaction.  In another transaction we remove it and modify the value.  We then roll the transaction back.  At this point we'd expect the pojo's value to be rolledback as well since we never committed the transaction.  But the value of the object is now changed.

       

      We're running this in a local mode so all the objects are in the same JVM.  We're using the JBoss JTA engine for the TransactionManager.

       

              Cache<String, Account> cache = m_cacheManager.getCache("transactionalCache");
              m_transactionManager = cache.getAdvancedCache().getTransactionManager();
             
              Account origData = new Account("id1", "value1");
            

              //
              m_transactionManager.begin();
              cache.put(origData.getId(), origData);
              m_transactionManager.commit();       
             

              //
              m_transactionManager.begin();
              Account fromCache = cache.remove(origData.getId());
              fromCache.setValue("new value");
              m_transactionManager.rollback();
             
              m_transactionManager.begin();
              Account fromCacheAfterRollback = cache.get(origData.getId());
              m_transactionManager.commit();
            

              // The value comes back as "new value"
              Assert.assertEquals("value1", fromCacheAfterRollback.getValue());

       

      Bryan

        • 1. Re: POJO rollback problem
          Manik Surtani Master

          Hmm, this would be because your second tx removes the entry (which returns a ref to the POJO), and then rolls back.  So no changes are written back to the cache.  But you still have a reference, and updating the reference will still have an effect within the same VM.  For example, if the 2 txs were on different VMs, you would not see the change propagate.

           

          This is one of the limitations of using POJOs in this manner, something we can work around using some pretty heavy-handed techniques (instrumenting your POJOs to listen for changes, or using proxies).

           

          In future the JPA-like API will offer proper support for POJOs (since proxies will be needed anyway to be able to generate deltas).

           

          You say the test passed sometime back?  Which version of Infinispan did this test work with?

          1 of 1 people found this helpful
          • 2. Re: POJO rollback problem
            Bryan Grunow Newbie

            Manik,

             

            I went back and tested a few 4.0 beta versions but it still didn't work.  I must have been thinking of a slightly different test or another data grid.  We're porting over all our tests from many different projects.

             

            Would this be an issue in distributed mode as well?  I'm thinking that if the request is made in Node A and the value comes from Node B then it would be serialized and sent to Node A.  If the transaction were rolledback then I doubt the changed value would go back to Node B.  But if Node A requested a value that happens to be in Node A then it would get the reference and not a copy and therefore you could get inconsistent behaviour.

             

            When you say future JPA do you mean 5.0 or later?  I know JPA is slated for the 5.0 timeframe but I don't know when this would fit.

             

            Anyhow, This is an issue for us and I'll be looking into some solutions.

             

            Bryan

            • 3. Re: POJO rollback problem
              Manik Surtani Master

              It shouldn't be a problem if you are using a clustered mode.

               

              I was referring to 5.0 when I mentioned the JPA-like API.

               

              HTH

              Manik

              1 of 1 people found this helpful