[jboss-dev-forums] [Design of EJB 3.0] - Transaction behavior of clustered SFSB caching

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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077944#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...