Discussions

EJB design: Doom (rollback) a transaction in differenct EJBContexts

  1. (1)By way of calling the setRollbackOnly() method on the EJB context object, a transaction with container-managed transaction can be doomed.
    (2)Container-managed transactional beans can detect doomed transactions by calling the getRollbackOnly() method on the EJB context object. If this method returns true, the transaction is doomed.

    Based on the above two points:
    -----------------------------
    Suppose, two beans Bean1, Bean2 are deployed in different servers, so their EJBContext’s are different.

    Bean1 is deployed in EJBContext1; Bean2 is in EJBContext2 with ‘REQUIRED’ transactional attribute.

    Bean1 is calling Bean2. If anything happens wrong in Bean2, the transaction has to doom which starts in Bean1.

    My question is:
    Here, if we call setRollbackOnly() method in Bean2, how it is propagated to Bean1 to doom (rollback) the transaction.

    Please help me in this regard.
  2. Kishore ,
      I would assume that this being a distributed txn case it would be a XA protocol with 2 Phase Commit. Hence all the resources in the txn is handles by a txn manager who holds the context info and in case any one txn is rolledback all the txns in the same txns would be rolledback. Does that anwser you question ?

    Cheers
    Deb
  3. Excuse the typos ...[ Go to top ]

    Excuse the typos in my previous message. It completely changed the meaning . The corrected one is as follows :
      
    I would assume that this being a distributed txn case it would be a XA protocol with 2 Phase Commit. Hence all the resources in the txn is handled by a txn manager who holds the txn context info and in case any one resource is rolledback all the resources in the same txns would be rolledback. In this case the resrouces are your EJBs and txnManager of your app servers work in co operation. Does that anwser your question ?

    Cheers
    Deb