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?

http://www.theserverside.com/discussions/thread.tss?thread_id=24987

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).

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.

try{
insert();

}catch(SQLException ex) {
context.setRollbackOnly();
}


Hope this help,
Senthil.

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.

-arun

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
exception:
• 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).