-
1. Re: Transaction behavior of clustered SFSB caching
brian.stansberry Aug 24, 2007 5:39 PM (in response to 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 Aug 27, 2007 6:11 AM (in response to brian.stansberry)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 Aug 27, 2007 10:20 AM (in response to 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 Oct 8, 2007 12:54 PM (in response to brian.stansberry)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 Oct 10, 2007 10:33 AM (in response to brian.stansberry)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 Oct 10, 2007 11:55 AM (in response to brian.stansberry)With this can we get rid of the SimplePassivatingCache.Entry concept?
-
7. Re: Transaction behavior of clustered SFSB caching
wolfc Oct 10, 2007 12:21 PM (in response to brian.stansberry)No I expand upon the concept, with SimpleLongevityCache.Entry. :-)
-
8. Re: Transaction behavior of clustered SFSB caching
brian.stansberry Oct 10, 2007 1:09 PM (in response to 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.