8 Replies Latest reply on Oct 10, 2007 1:09 PM by brian.stansberry

    Transaction behavior of clustered SFSB caching

    brian.stansberry

      Discussion thread related to http://jira.jboss.com/jira/browse/EJBTHREE-845.

      Original intent of the JIRA was to examine if it made sense to have the JBoss Cache used for SFSB replication participate in any transaction associated with the request.

      My take on this was that this was a bad idea. If JBC participates in the transaction, and the tx rolls back, any changes made to the cache during the course of the transaction will be rolled back. The effect is the copy of the bean in the cache will be reverted to the version that existed before the tx started (even if the bean was removed during the tx). While that kind of behavior might be something some users would enjoy, IMHO it's not something the SFSB cache should be doing.

      However, a side effect of not using transactions is we currently replicate the SFSB after every invocation. Very chatty, and wasteful if a tx is in effect. If a tx is in effect, the client side proxy won't allow a failover anyway after a call has reached a server. So there's no point replicating state prior to tx commit.

      A possible improvement we discussed last month in Austin is to use the JBC BatchModeTransactionManager to control replication. BTM is basically a simple TM with functionality sufficient to trigger the JBC's "batch" functionality. See http://wiki.jboss.org/wiki/Wiki.jsp?page=BatchModeTransactionManager .

      Basic idea here is:

      1) StatefulReplicationInterceptor has reference to BTM. Uses it to check if there is a BTM tx associated with the caller thread. If yes, call proceeds as normal.
      2) If no, check if there is a regular JTA tx associated with the invocation. If yes, start a BTM tx, and register a Synchronization with the JTA tx.
      2a) In afterCompletion() callback, commit the BTM tx, thus triggering replication. (Hmm -- doing work in afterCompletion() isn't so good).

      We commit the BTM tx whether the JTA tx completes successfully or not. Committing the BTM tx is what causes replication to occur; good or bad the current state of the cache needs to replicate to ensure consistency across the cluster.

        • 1. Re: Transaction behavior of clustered SFSB caching
          brian.stansberry

           

          If a tx is in effect, the client side proxy won't allow a failover anyway after a call has reached a server. So there's no point replicating state prior to tx commit.


          Hmm, this comment was based on the behavior of the old detached invoker InvokerProxyHA impls. Looking at the ClusterChooserInterceptor used by EJB3, I don't see this functionality. Anyone know if 1) this is an oversight or 2) this was deliberately left out or 3) Brian's a moron?

          • 2. Re: Transaction behavior of clustered SFSB caching
            slaboure

            Brian,

            Could you please also make sure we have the option to replicate multiple SFSB in a single Web request? Seam can make usage of multiple SFSB that it will store in its HTTPSession. When a web request comes in, it might change state in the http session as well as many related SFSB (stored into this http session). Ideally, we want one batch replication for all related state, not n-replications.

            Can this behaviour be mimicked by grouping these operations in a "transaction" (or a related but weaker notion), as you suggested in your previous post?

            Cheers,


            sacha

            • 3. Re: Transaction behavior of clustered SFSB caching
              brian.stansberry

              Sacha,

              Yep, that's the goal. There's really 2 levels to what you're talking about:

              1) Batching all the SFSB replication from various beans accessed in the request into one replication event. What I described above should handle that nicely, since all the beans are cached in the same JBC instance. When the BTM tx is committed, they all replicate in one event.

              2) Doing the web session replication with the SFSBs. Currently this won't work, because web sessions and SFSBs are stored in different JBC instances, and each cache will replicate separately. I can use the same BatchModeTransactionManager for both services, so getting the batching control to properly span the entire request should be doable. But I also need to get everything into one cache. I *might* be able to do that with the current infrastructure, since both caches use largely the same configuration (pretty likely I can). If not, this will need http://jira.jboss.com/jira/browse/JBCACHE-64 completed, which is a next year thing.

              • 4. Re: Transaction behavior of clustered SFSB caching
                wolfc

                Replication should take place after tx completion (regardless of commit or rollback). With the new ejb3-cache this should be done on release of the SFSB.

                Note that in the current implementation beans which do not implement SessionSynchronization release after method call. This strikes me as bad behaviour. We should always have a SFSB participate in the tx and release it on tx completion.

                • 5. Re: Transaction behavior of clustered SFSB caching
                  wolfc

                  I've modified the cache spi to allow for an lifecycle over multiple invocations (LongevityCache).

                  • 6. Re: Transaction behavior of clustered SFSB caching
                    brian.stansberry

                    With this can we get rid of the SimplePassivatingCache.Entry concept?

                    • 7. Re: Transaction behavior of clustered SFSB caching
                      wolfc

                      No I expand upon the concept, with SimpleLongevityCache.Entry. :-)

                      • 8. Re: Transaction behavior of clustered SFSB caching
                        brian.stansberry

                        I'll have to see if I can get the concept to work with JBC as the backing caching system. SimplePassivatingCache will not work with JBC.