java.sql.SQLException does not extend java.lang.RuntimeException or java.rmi.RemoteException, which means that it is an application exception. It is really a pity that the default behaviour is to commit application exceptions. At JavaONE I got the opportunity to ask the EJB spec team why this was changed from version 1.0 to 1.1 of the EJB spec. They did not give any technical background to the change. Instead they referred to customer demands. It would be very interesting to here the motivation for racing the demand. Who are the customers? The Vendors?
/Johan -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Hement Sasan Sent: den 28 december 2001 12:52 To: [EMAIL PROTECTED] Subject: Transactions not being handled properly in Stateless Session bean s with CMT Hi, I am developing some stateless session beans, in which the beans' methods are performing some database operations (insert, update directly and also through stored procedures). Beans are declared CMT and all methods in all the beans have attribute *Required*. So, all the transactions are being handled by container. In one of the bean, one of the method is getting a collection of Object type, say ABC, getting iterator on it, and then using the while loop on this iterator saving (inserting) all the objects in database. In some cases (for testing purpose) the collection comes with two or more records with same primary key. In this case, an SQL exception should be thrown and the transaction should be rolled back. Here's what's happening actually: SQL Exception is thrown, but rollback(ing) is not being done. what ever records were inserted before this exception occurred (in the while loop) get committed. What may be the problem in the above case? As SQL exception is not an application exception (or is it not considered a system exception?), container should have set Rollback true. Do I need to use setRollbackOnly in case of non-Application exceptions and errors also? The same is happening in case of calling stored procedures also. Even if an SQL exception comes after returning from stored procedure, what ever is done in the stored procedure gets committed. Env: Weblogic v6.0 with sp2 OS: Win 2K DB: MSSQL server 2000 I'm using Transactional Data Source, with two phase commit. Any insight comments to this problem would be greatly appreciated. Thanks, - Hement =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
