2 Replies Latest reply on Oct 17, 2008 10:39 AM by galder.zamarreno

    Transaction Stickiness in heterogeneous/homogeneous deployme

    galder.zamarreno

      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?