[jboss-dev-forums] [Design of Clustering on JBoss] - Transaction Stickiness in heterogeneous/homogeneous deployme

[galder.zamarreno@jboss.com]

I was thinking and running some further error situation tests with regards to transaction stickiness and I came to the conclusion that transaction stickiness only makes sense in a homogeneous deployment scenario, not in a heterogeneous one. 

When ut.begin() is called, wherever it lands, all the EJBs that are gonna be called until commit/rollback need to be in that node, otherwise the transaction fails (no failover allowed within a transaction). At ut.begin(), we can't know that "X node has all the EJBs that I'm gonna need for this transaction". So, I think this is a sensible assumption, what do you think?

For example, the following sounds reasonable to me:

- EJB1 and EJB2 deployed in nodes A and B.
- User transaction sticky started that calls EJB1 and EJB2 continuously and the stickyness landed in node A.
- During this transaction, EJB1 and EJB2 are undeployed from node A which results of transaction failure.
- UserTransaction is looked up again (HA-JNDI) and new transaction began. Assuming that node B replied to the lookup, everything is fine, EJB1 and EJB2 are deployed there.
- After commit(), you call begin() again which is now load balanced to node A but EJB1 and EJB2 are not deployed there so it fails. I think this is reasonable failure because EJB1 and EJB2 are longer in node A and at begin(), we can't know whether all or any of the EJBs we're gonna call are in that node.

Thoughts?

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

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