Thanks a lot. Johan, the reason I might think of deciding (by EJB spec team) to not doing rollback in case of Application Exceptions would be to allowing the developer to choose if she wants to let the transaction rollback (by calling setRollbackOnly) or let it get committed (default). In case of rollback as default in application exceptions, developer won't have choice to commit the part of transaction that has taken place so far. Though I'm not sure under what conditions would a developer want to commit a *transaction* even if some part of it failed, as then this would not be a *transaction* in real sense.
Cheers, - Hement > -----Original Message----- > From: Johan Eltes [SMTP:[EMAIL PROTECTED]] > Sent: Friday, December 28, 2001 6:22 PM > To: Sasan, Hement; [EMAIL PROTECTED] > Subject: RE: Transactions not being handled properly in Stateless > Session bean s with CMT > > 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".
