Transaction Rollback in Stateful Session Bean


EJB programming & troubleshooting: Transaction Rollback in Stateful Session Bean

  1. Transaction Rollback in Stateful Session Bean (3 messages)

    Sorry i misposted it earlier in the wrong forum

    hi all,
    When there is a transaction roll back in a stateful session bean, the bean object gets deleted and we get the console message "Bean has been deleted".
    Only when the server is restarted, we are able to get new instance of the deleted bean.
    Pls. suggest a solution.
  2. Question: Are you using BMT or CMT. I believe CMT is used.

    If the answer really is CMT, I believe there is no way to stop the EJB container from discarding the bean instance after a rollback, no matter whether you signal the container by a. calling SessionContext.setRollbackOnly(), or b. throwing a new EJBException, or c. ignoring any RuntimeException.

    I believe the only solution in the case of a stateful session bean is to use BMT and implement the SessionSynchronization interface. You make your own tx.rollback() call, and restore the client state within the afterCompletion() method.
  3. hi eric,
    thanx for ur response. i do use CMP.
    In CMP Stateful Session Bean if there is no way to handle transaction roll back then the conclusion would be
    CMP Stateful Session Beans are of no use...isn't it?
    Because any transaction will meet some sort of rollback.
  4. I assume you meant CMT when you said CMP. I wouldn't make such a conclusion lie you did. Stateful session beans should be used with care, but they definitely serve purposes that other types of EJB's cannot serve. Please refer to any standard EJB text for details of EJB transaction management and exception handling. Basically, with any kind of EJB, if a TX rollback is caused by the bean throwing a system exception (such as EJBException or RuntimeException), the bean instance is automatically discarded because any state it encapsulates maybe invalid. You may want to double check the case where the rollback is caused by calling the EntityContext.setRollbackOnly(). This may or may not lead to EJB container discarding the bean instance. Alternatively, use BMT as I initially suggested.