8 Replies Latest reply on May 23, 2005 6:00 PM by a045103

    Transaction commit and replication

    a045103

      I have a question about transactions and replication where TreeCache is used as a hibernate 2nd-level cache.

      The scenario is where I update a hibernate object that is cached. When the hibernate transaction is commited, is the cache replication done as part of the transaction (and rolled back if the commit to the database is rolled back), or is the cache replication and its associated transaction initiated when the hibernate transaction completes?

      Thanks.

      /doug

        • 1. Re: Transaction commit and replication

          Yes, that's supposed to be the behavior except the query cache, AFAIK.

          -Ben

          • 2. Re: Transaction commit and replication
            a045103

            Does the replication happen on another thread, such that after the JTA transaction commits (initiating the replication), it can perform other work in parallel with the replication?

            • 3. Re: Transaction commit and replication

              You can set the treecache.xml cacheMode from REPL_SYNC to REPL_ASYNC such that you have more concurrency.

              Check the documentation.

              -Ben

              • 4. Re: Transaction commit and replication
                a045103

                Ok - so if you go synch, the JTA transaction commits, after which if you're using REPL_SYNCH, the cache state is replicated across the cluster in a 'TreeCache' transaction. If you go asynch, the replication happens asynchronously with respect to the thread the JTA transaction occurs on.

                Are the replication transaction semantics the same for both REPL_SYNCH and REPL_ASYNCH? The docs seem to imply that the cache contents could be inconsistent across cache members if error occur when REPL_ASYNCH is used.

                Finally, if an error occurs in the replication, and REPL_SYNCH is used, is an exception thrown? Is there a recommended error strategy, like evicting the data modified in the transaction since it is inconsistent with the resource manager? I assume any exception thrown does not affect the outcome of the JTA transactions as it has been committed prior to replication...

                Thanks again for the replies - this is very helpful.

                /doug

                • 5. Re: Transaction commit and replication

                  Asynchonous replication implies that the JTA context doesn't span to the other node. Once it is out of the wire (in the prepare phase), it returns successfully and tx is ready to commit.

                  Synchronous will wait for the replication result before going to commit stage or rollback.

                  -Ben

                  • 6. Re: Transaction commit and replication
                    a045103

                    If you use REPL_SYNCH, does JBoss cache participate in the transaction as a resource manager?

                    /doug

                    • 7. Re: Transaction commit and replication

                      Yes, but it is not 2PC yet though.

                      -Ben

                      • 8. Re: Transaction commit and replication
                        a045103

                        Can replication failures in a REPL_SYNCH scenario put some members of the cache out of sych with other members of the cluster, or does it cause the JTA transaction to be rolled back? Is consistency guaranteed for this scenario?

                        Is it fair to say that if we use REPL_ASYNCH, we trade safety for speed, as if a cluster member fails to process the update, it's state may be inconsistent with other members of the cluster?

                        Thanks for your patience - I think I'm on the verge of getting it ;-)

                        /doug