why not rollback


EJB programming & troubleshooting: why not rollback

  1. why not rollback (4 messages)

    I have a test method in my sessions bean like:

    cx = getDBConnection(dsnName);
    stmt = cx.createStatement();
    rs = stmt.executeQuery(qstr);

    the qstr="insert into table(a) values ('1')"

    when I execute it,I got error java.sql.SQLException: No Result Set was produced.

    the transacrion-attribute is required

    since there is error,I thought the container should rollback the transaction automatically,but when I check database,the record is inserted,why?

    Threaded Messages (4)

  2. why not rollback[ Go to top ]


    Make sure that your connection pool attributes are correctly setup. Also, if you are inserting a row, use:

    int impactedRowCount = stmt.executeUpdate(qstr);

    This will return a number that should be equal to the number of rows inserted (1 in your case).
  3. why not rollback[ Go to top ]

    I think you can try/catch SQLException and in the catch block, you can invoke context.setRollbackOnly(). That will rollback the transaction.

    Basically when you use CMT the container will rollback only if there any System Level Exceptions. I am not sure, the SQLException is a System Level Exception.


    }catch(SQLException ex) {

    Hope this help,
  4. why not rollback[ Go to top ]

    In the try-Catch log the message and throw EJBException, which will roll back the current transaction. SQLExcetion will not roll back though its a system exception.

  5. why not rollback[ Go to top ]

    Thought this would help - extract from 2.0 spec.

    "The Container catches a non-application exception; logs it (which can result in alerting the System Administrator); and, unless the bean is a message-driven bean, throws the java.rmi.RemoteException (or subclass thereof) to the client if the client is a remote client, or throws the javax.ejb.EJBException (or subclass thereof) to the client if the client is a local client. The Bean Provider can rely on the Container to perform the following tasks when catching a non-application
    • The transaction in which the bean method participated will be rolled back.
    • No other method will be invoked on an instance that threw a non-application exception.
    This means that the Bean Provider does not have to perform any cleanup actions before throwing a non-application exception. It is the Container that is responsible for the cleanup."

    I was wrong saying SQLException is SystemException. Because they are not runtime exceptions. They need to be considered as app-exception because the client needs to react to an sqlexception (depending the operation).