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?
