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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...