Discussions

EJB design: EJB Transaction Issue

  1. EJB Transaction Issue (2 messages)

    SLSB calls DAO,the DAO's use jdbc code like setAutoCommit(false) & all other jdbc commit and rollback methods for Tx control . SLSB are set to "Bean" transaction type. Is there any transaction issue happens? Also we use MDB ,onMessage() method process message and last it updated DB.This MDB is set to Bean type Tx. We've taken care of redelivery of message if any thing occurs .

    Threaded Messages (2)

  2. EJB Transaction Issue[ Go to top ]

    Hi,

    I hope you have a really good reason for using bean managed transactions. Otherwise, my recommendation is to use the container's TX management. It will save you a lot of time in the development.

    You should not call setAutoCommit, commit, or rollback in you EJB code. Section 17.3.3 in the EJB 2.1 specification. You must use InitialContext.getUserTransaction to the the transaction, and then commit on that object. (In real lift, I think the container will throw an exception if you call, for example, commit on a JDBC connection obtained from the container.)

    I you use a message driven bean with bean TX, the rollback will _not_ include a rollback of the message to the queue. The message is read! I find this clear from section 15.4.8 in the EJB 2.1 spcification.

    I think sections 15.4.8 and 18.2.2 must be interpreted i nthe following way: If you have a messag driven bean with container TX, and you throw a RumtimeException (or subclass) from it, there will be a complete rollback _including_ the rollback of the message to the queue! This means you JMS implementation must handle this is some nice way, otherwise you will definitely have an infinite loop.

    My recommendation here is to suuround the code in the message driven bean (with container TX) with a hughe try/catch(RuntimeException) block and handle the logging of failures on you own. Or if you really trust you middelware/JMS implementation use it to take care of the problem. Maybe this is more a question about where you want to get the error. Where will the system administrator look first?

    regards,
    Tomas
  3. EJB Transaction Issue[ Go to top ]

    Hi,I hope you have a really good reason for using bean managed transactions. Otherwise, my recommendation is to use the container's TX management. It will save you a lot of time in the development.You should not call setAutoCommit, commit, or rollback in you EJB code. Section 17.3.3 in the EJB 2.1 specification. You must use InitialContext.getUserTransaction to the the transaction, and then commit on that object. (In real lift, I think the container will throw an exception if you call, for example, commit on a JDBC connection obtained from the container.)I you use a message driven bean with bean TX, the rollback will _not_ include a rollback of the message to the queue. The message is read! I find this clear from section 15.4.8 in the EJB 2.1 spcification.I think sections 15.4.8 and 18.2.2 must be interpreted i nthe following way: If you have a messag driven bean with container TX, and you throw a RumtimeException (or subclass) from it, there will be a complete rollback _including_ the rollback of the message to the queue! This means you JMS implementation must handle this is some nice way, otherwise you will definitely have an infinite loop.My recommendation here is to suuround the code in the message driven bean (with container TX) with a hughe try/catch(RuntimeException) block and handle the logging of failures on you own. Or if you really trust you middelware/JMS implementation use it to take care of the problem. Maybe this is more a question about where you want to get the error. Where will the system administrator look first?regards,Tomas
    Section 17.3.3 in the EJB 2.1 specification. I've checked the spec. It doesnt say that commit,setAutoCommit methods are not used.
    May be I'm wrong, but I understood as the mixing of UserTranscation API and commit,rollback or setAutoCommit() methods of JDBC is not
    allowed. I'm still confuse, can we use only jdbc Tx control api with out UserTransaction API.