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

"bstansberry(a)jboss.com" wrote : 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. V good point. Testing having to start AS and deploy stuff is quite heavyweight and makes the tests take much longer. I agree with you and so, I'll look into how to resolve this via simpler UTs. "bstansberry(a)jboss.com" wrote : 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. :( | Serialization change and having to add configuration for EJB3 on top of EJB2 seems two good reasons to create separate load balance policies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080302#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...