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?
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?
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.
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.
I've modified the cache spi to allow for an lifecycle over multiple invocations (LongevityCache).
With this can we get rid of the SimplePassivatingCache.Entry concept?
No I expand upon the concept, with SimpleLongevityCache.Entry. :-)
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.