[jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

galder.zamarreno@jboss.com do-not-reply at jboss.com
Fri Aug 31 13:49:47 EDT 2007


"bstansberry at jboss.com" wrote :  Re: the different invoker types, is it a big deal to do them all?  I suppose the biggest hassle is testing.  Do you think it's possible to unit test this with mock objects, letting you basically plug in the different invokers into the same test fixture without having to deploy to the AS?

Without deploying to AS?Hmmmmm, not sure. My current tests for 4.0.x worked by deploying EJBs using Mock invoker/invokerproxy versions that injected failures. I can look into it though.

"bstansberry at jboss.com" wrote :  One reason to fix them all is that I believe the current mechanism for checking if failover is allowed is broken; i.e it uses the Transaction from Invocation.getTransaction() rather than the TransactionPropagationContext.  Thus it misses the case where UserTransaction is used.  So, fixing that is a side benefit of JBAS-4555.

+1

Ok, I'll implement this for all invokers and will look into the most efficient way to unit test them all.

Re: different load balance load balance policies

Couple of questions came to my mind here:
1.- Rather than implementing 4 brand new policies, it might be easier to add a new element to cluster-config XML called transaction-sticky with true/false values and modify the existing load balance policies to act upon the value of that element, what do you think? This hasn't been fully baked, it's just something that I had in mind.
  
2.- Should transaction sticky (either implementations or solution mentioned in 1) be the default? IMO, 4.x should maintain existing (default) behavior while transaction sticky should be default in trunk. Thoughts? 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080109#4080109

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080109



More information about the jboss-dev-forums mailing list