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

[galder.zamarreno@jboss.com]

I had a prototype of this solution for a while, but I had encountered some issues while attempting to finalise it. These issues are (except for EJB3) now resolved and while looking back at the prototype, I came across this:

At the beginning of the invocation, I do a get on the tx failover map passing the current tpc. If it returns not null, I  add it to the invocation transient payload so that the load balance policy can choose the right target. Also, after the invocation has returned, I get the transaction sticky target from the transient map and put it with the tpc in the tx failover map. So far so good. 

At the moment, before these two sections, I check whether the load balance policy is instanceof TransactionSticky. This class does the work of checking whether a chosen target is in the invocation transient payload and if it isn't, delegates to a standard lbp). There're 4 matching versions (FA, R....etc) of TransactionSticky, each containing a delegate for the standard type. These matching lbps extend TransactionSticky.

There's a problem though with just doing instanceof TransactionSticky. Pre transaction sticky clients would get a nice CNFE. I can see two alternatives:

1.- do not check instanceof TransactionSticky and do the lookup in the tx failover map and put the result as chosen target in the invocation transient map regardless. For non sticky versions, it would null would be returned from the map lookup and null would be put in the inv transient map. This would mean that all transactional invocations would have 3 added map operations added to the cost of the invocation. Not good and makes the code less readable.

2.- add a transient boolean instance variable to each proxy with the value of T.getCurrentT().getCCL().loadClass(TransactionSticky) being successfull AND lbp instanceof TransactionSticky returning true. I could then use this parameter in the proxy to avoid unnecessary map get/puts. This solution would safe 3 map operations per transactional invocation for non tx sticky situations. 

Both this solutions avoid possible issues with pre transaction sticky clients that won't have those classes. My personal preference is with 2, although I'm not 100% sure about the cost of a loadClass() vs cost of a map operation. I do imagine though that if clients cache the proxy and reuse it, the having the transient boolean option would perform much better.

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

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