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

[bstansberry@jboss.com]

"galder.zamarreno at jboss.com" wrote : 
  | Ok, I'll implement this for all invokers and will look into the most efficient way to unit test them all.

Good. Take the "don't deploy in AS" thing as just an idea I threw out.  That comes from a general feeling I have that unit testing in clustering is inadequate because it's too hard to 1) write complex deployment descriptors that cover all the cases, package them  and then deploy them 2) properly check system state when you can only expose that state via JMX or as part of a web or ejb response.

anonymous wrote : 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.

Hmm. I don't want to reject that idea yet, but I'm concerned about pushing more config stuff into both EJB3 and EJB2. Plus, theoretically these policies can be used outside of EJB, so we'd have to find a way to expose the option wherever they are used.

Also, doing that requires a new field in the LBP impls, which changes their serialization.  That will break clients using the old versions, so no good in 4.x and something to avoid in 5.

Also means changing the LBP interface to add a setTransactionSticky(boolean) method.

I know where you're coming from though.  The proliferation of classes gets worse when we start talking about doing things properly for Remoting based proxies (e.g. EJB3) vs. the existing detached invoker-based ones. LoadBalancePolicy.chooseTarget (FamilyClusterInfo clusterFamily, Invocation routingDecision) is not meaningful in a Remoting based proxy, because the "org.jboss.invocation.Invocation" class is not used, "org.jboss.aop.joinpoint.Invocation" is.  So, handling that doubles the number of classes. :(
  
anonymous wrote : 
  | 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? 

+1

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

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