5 Replies Latest reply on Jun 3, 2008 6:18 AM by Manik Surtani

    No transactionality in caches

    Jorge Morales Master

      I have read in the doc's that it is possible to not configure a TransactionManager at all for the caches, and these will behave like an auto-commit.

      We are experiencing transactional timeouts in the Arjuna Two-Phase commits, in our production environment, probably network issues. Until we solve this issues, we are planning on eliminating transactionality, we can go without it for the cache.

      Would this work as expected?

      I'm doing some tests but in the TxInterceptor I dont see anything, using or without using the TransactionManager.

        • 1. Re: No transactionality in caches
          Manik Surtani Master

          Are you using optimistic locking? If so, you need a transaction manager.

          If not, you can disable the use of transactions either by not registering a TM n your JBC config, or just making sure there isn't a tx already started when you start interacting with the cache (perhaps suspend any ongoing transactions first).

          • 2. Re: No transactionality in caches
            Jorge Morales Master

            Why is it needed for optimistic locking? What if it is a single node cluster cache?


            • 3. Re: No transactionality in caches
              Manik Surtani Master

              Optimistic locking still requires a transaction manager since nodes are versioned and copied into your transaction workspace that you interact with. Changes are then merged back into the main data structure when you commit.

              • 4. Re: No transactionality in caches
                Kevin Duncliffe Newbie

                The comment above about making sure a transaction hasn't already started intrigues me.

                We're using *pessimistic* locking, but we are also using Spring's HibernateTransactionManager (specifically, annotation-based declarative transaction management).

                If we are not using HibernateTransactionManager to support optimistic locking, should we still be able to use HibernateTransactionManager with JBoss Cache in a clustered environment, for pessimistic locking? If JBoss Cache throws a ReplicationException, for example, shouldn't HibernateTransactionManager still roll back the transaction?

                Because we are seeing ReplicationExceptions and cache inconsistency, even with pessimistic locking and replication sync, I am also wondering if we are on the wrong road entirely by attempting to use JBoss Cache without JTA, even with pessimistic locking.

                We are running on

                -- Tomcat 6.0.14
                -- Spring 2.0.4
                -- Hibernate 3.2.5
                -- JBoss Cache 1.4.1.SP9

                Thanks in advance for any insights.

                • 5. Re: No transactionality in caches
                  Manik Surtani Master

                  To participate in transactions, JBC needs a reference to a JTA transaction manager. I'm guessing HibernateTransactionManager is not a Hibernate class at all, but a Spring one? If this is JTA compliant (i.e., implements javax.transaction.TransactionManager) then you can write a transaction manager lookup for it and specify your transaction manager lookup implementation in your JBoss Cache config.

                  If you need a standalone JTA compliant transaction manager there are several good OSS ones out there, including JBoss Transaction Manager.