Thanks for the reply Bob - great feedback. I've a few follow-up questions if you don't mind.
> Yes, they have the same effect as both are "system" exceptions, but > throwing a system exception to roll back a transaction is not a good > practice. Currently I'm catching CreateExceptions & FinderExceptions in my session bean methods, and throwing EJBExceptions to the delegates. I'm calling setRollbackOnly() before throwing application exceptions. The delegates catch the RemoteExceptions that wrap the EJBExceptions, and of course also catch the application exceptions. So are you saying that I should modify my session beans to re-throw the Create + Finder Exceptions, instead of throwing EJBExceptions ? And I guess I should call setRollbackOnly() if these exceptions are thrown after an update ? > First, the container must throw away the bean instance. Good point, though interestingly the J2EE tutorial says it 'might', as opposed to 'must': "If a system exception is thrown, the EJB container might destroy the bean instance." http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/BMP6.html#63681 Even so, 'might' is still a good enough reason, thanks. > Second, the container is not required to propagate runtime exceptions > back to the client. As you essentially told the container that a system > level error has occured (i.e. a network failure, or the database is > down), it may try the request again on another machine, etc. Thanks, I didn't know that. But isn't it written somewhere in the spec that the container must propagate it, eventually at least, back to the client (wrapped in a RemoteException) ? > In other words, if you're canceling the transaction based on an application level > condition, explicitly roll it back. I agree - I already call setRollbackOnly() before throwing an application level exception. Thanks, -Paul > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Bob Lee > Sent: Wednesday, December 18, 2002 11:47 AM > To: [EMAIL PROTECTED] > Subject: Re: EJBException vs RuntimeException (was CMP Transactions) > > > Yes, they have the same effect as both are "system" exceptions, but > throwing a system exception to roll back a transaction is not a good > practice. First, the container must throw away the bean instance. > Second, the container is not required to propagate runtime exceptions > back to the client. As you essentially told the container that a system > level error has occured (i.e. a network failure, or the database is > down), it may try the request again on another machine, etc. In other > words, if you're canceling the transaction based on an application level > condition, explicitly roll it back. > > Thanks, > Bob > > > Paul Kavanagh wrote: > > Is throwing a RuntimeException in a session bean method (in order to roll back the >tx) > the same as > > throwing an EJBException (which of course is a subclass of RuntimeException) ? We'd > like to use a > > subclass of RuntimeException to add logging etc, but are wondering if the container > does anything > > differently when it sees this particular subclass. > > > > Thanks in advance, > > -Paul > > > > > > > >>-----Original Message----- > >>From: A mailing list for Enterprise JavaBeans development > >>[mailto:[EMAIL PROTECTED]]On Behalf Of saroj kumar > >>Sent: Tuesday, December 17, 2002 5:45 AM > >>To: [EMAIL PROTECTED] > >>Subject: Re: CMP Transactions > >> > >> > >>Hi Juan, > >> > >>Subclassing will work but doesn't that defeat the purpose > >>Behind System Exception. As System exception means that there > >>Is unrecoverable exception and "Bean Instance" needs to be discarded. > >>But, here we will be throwing a kind of system exception to indicate > >>Business Exception. > >> > >>Moreover, it makes life miserable if you want to do some update > >>In the method and then throw the exception. > >> > >>Example: I need to update DB to indicate no. of times login failed. > >> > >>I just try to login and if it is not the correct pwd then just need > >>To throw an Exception. Before throwing the exception, I need to update > >>the > >>DB column for failed attempts. If it were a Subclass of EJBException > >>then > >>I need to again Retry on the same bean after getting the same exception. > >> > >>If it were a business Exception then I need not retry. > >> > >>Having a mix of Checked Exception and Subclassed EJBException will > >>result > >>in explosion of Exceptions Which is not desirable. > >> > >>Last but not the least, Unchecked exceptions don't force to handle > >>The exception at compile time but may be a nasty surprise at Runtime. > >> > >> > >>-Saroj > >> > >> > >> > >> > >>>-----Original Message----- > >>>From: A mailing list for Enterprise JavaBeans development > >>>[mailto:[EMAIL PROTECTED]] On Behalf Of Juan Pablo Lorandi > >>>Sent: Tuesday, December 17, 2002 7:01 PM > >>>To: [EMAIL PROTECTED] > >>>Subject: Re: CMP Transactions > >>> > >>> > >>>That's defined that way only in EJB 1.1+(Exception handling, section 12 > >>>in EJB 1.1, section 18 in EJB 2.0); IMHO, the spec diverts in its > >>>Exception handling from "regular" java exceptions, because the > >>>underlying idea of application exceptions is that the bean's client may > >>>recover from them somehow(by retrying, by changing attributes, etc.). > >>> > >>>You're not prohibited to throw system exceptions, and it's a good > >>>practice to propagate exceptions. The point I did miss in my previous > >>>post is that when you throw an application exception (a checked > >>>exception, one that's not a subclass of RuntimeException), you should > >>>clean up first. Sort of: > >>> > >>>try { > >>> // some code > >>>} catch (SomeException e) { > >>> log.error("While doing Something", e); > >>> ctx.setRollbackOnly(); > >>> > >>> connection.close(); //release resources > >>> > >>> > >>> throw new AppException("While doing Something", e); //propagate > >>>errors. > >>>} > >>> > >>>Make AppException a subclass of javax.ejb.EJBException. > >>> > >>>To wrap it up, basically, your responsibilities as a bean provider are > >>>different depending on the severity of the Exception you've caught and > >>>their impact on your app. If you've encountered an exception > >>>(checked or > >>>not) that you cannot recover from, it's valid to rethrow it wrapped in > >>>EJBException, the TX rollbacks automatically, and the container is in > >>>charge of cleaning up. > >>> > >>>Juan Pablo Lorandi > >>>Chief Software Architect > >>>Code Foundry Ltd. > >>>[EMAIL PROTECTED] > >>> > >>>Barberstown, Straffan, Co. Kildare, Ireland. > >>>Tel: +353-1-6012050 Fax: +353-1-6012051 > >>>Mobile: +353-86-2157900 > >>>www.codefoundry.com > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: A mailing list for Enterprise JavaBeans development > >>>>[mailto:[EMAIL PROTECTED]] On Behalf Of Bob Lee > >>>>Sent: Monday, December 16, 2002 9:27 PM > >>>>To: [EMAIL PROTECTED] > >>>>Subject: Re: CMP Transactions > >>>> > >>>> > >>>>Actually, the container will only automatically roll back a > >>>>transaction when a system exception is thrown. You should > >>>>always roll back explicitly for an application exception. > >>>> > >>>>Bob > >>>> > >>>>Juan Pablo Lorandi wrote: > >>>> > >>>>>Depends on the kind of transaction, and the EJB spec > >>>> > >>>you're working > >>> > >>>>>against. Best is to do both: mark the transaction for > >>>> > >>>>rollback, then > >>>> > >>>>>rethrow the exception; just rethrowing the Exception will > >>>> > >>>work with > >>> > >>>>>most app servers and is a good programming practice. > >>>>> > >>>>>Sample: > >>>>> > >>>>>try { > >>>>> // some code > >>>>>} catch (SomeException e) { > >>>>> log.error("While doing Something", e); > >>>>> ctx.setRollbackOnly(); > >>>>> throw AppException("While doing Something", e); > >>>>>} > >>>>> > >>>>>My 2c, > >>>>> > >>>>> > >>>>>Juan Pablo Lorandi > >>>>>*Chief Software Architect* > >>>>>Code Foundry Ltd. > >>>>>[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > >>>>> > >>>>>Barberstown, Straffan, Co. Kildare, Ireland. > >>>>>Tel: +353-1-6012050 Fax: +353-1-6012051 > >>>>>Mobile: +353-86-2157900 > >>>>>www.codefoundry.com <http://www.codefoundry.com/> > >>>>> > >>>>>Disclaimer: > >>>>> > >>>>>Opinions expressed are entirely personal and bear no relevance to > >>>>>opinions held by my employer. Code Foundry Ltd.'s opinion > >>>> > >>>is that I > >>> > >>>>>should get back to work. > >>>>> > >>>>> -----Original Message----- > >>>>> *From:* A mailing list for Enterprise JavaBeans development > >>>>> [mailto:[EMAIL PROTECTED]] *On Behalf Of > >>>> > >>>>*BOUTTE Sebastien > >>>> > >>>>> *Sent:* Monday, December 16, 2002 4:02 PM > >>>>> *To:* [EMAIL PROTECTED] > >>>>> *Subject:* CMP Transactions > >>>>> > >>>>> Hi, > >>>>> > >>>>> I would like to know if i have to called method > >>>> > >>>>setRollBackOnly on > >>>> > >>>>> session context > >>>>> when i want to rollback current transaction or rethrow > >>>> > >>>>the exception > >>>> > >>>>> to the container, and let it do the rollback ? > >>>>> > >>>>> Thanks > >>>>> > >>>>> S�bastien Boutt� > >>>>> > >>>>> > >>>>> > >>>> > >>>---------------------------------------------------------------------- > >>> > >>>>>-- > >>>>> > >>>>> Ce message est prot�g� par les r�gles relatives au secret des > >>>>> correspondances ; il peut en outre contenir des informations � > >>>>> caract�re confidentiel ou prot�g�es par diff�rentes r�gles et > >>>>> notamment le secret des affaires ; il est �tabli � destination > >>>>> exclusive de son destinataire. Toute divulgation, utilisation, > >>>>> diffusion ou reproduction (totale ou partielle) de ce > >>>> > >>>>message, ou > >>>> > >>>>> des informations qu'il contient, doit �tre > >>>> > >>>>pr�alablement autoris�e. > >>>> > >>>>> Tout message �lectronique est susceptible d'alt�ration et son > >>>>> int�grit� ne peut �tre assur�e. WFinance et WFinance Conseil > >>>>> d�clinent toute responsabilit� au titre de ce message > >>>> > >>>s'il a �t� > >>> > >>>>> modifi� ou falsifi�. Si vous n'�tes pas destinataire de > >>>> > >>>>ce message, > >>>> > >>>>> merci de le d�truire imm�diatement et d'avertir l'exp�diteur de > >>>>> l'erreur de distribution et de la destruction du message. > >>>>> > >>>>> This message is protected by the secrecy of > >>>> > >>>>correspondence rules ; > >>>> > >>>>> furthermore it may contain privileged or confidential > >>>> > >>>>information > >>>> > >>>>> that is protected by law, notably by the secrecy of business > >>>>> relations rule ; it is intended solely for the attention of the > >>>>> addressee . Any disclosure, use, dissemination or reproduction > >>>>> (either whole or partial) of this message or the information > >>>>> contained herein is strictly prohibited without prior > >>>> > >>>>consent. Any > >>>> > >>>>> electronic message is susceptible to alteration and its > >>>> > >>>>integrity > >>>> > >>>>> can not be assured. WFinance and WFinance Conseil declines any > >>>>> responsibility for this message in the event of alteration or > >>>>> falsification.. If you are not the intended recipient, please > >>>>> destroy it immediately and notify the sender of the > >>>> > >>>>wrong delivery > >>>> > >>>>> and the mail deletion. > >>>>> > >>>>> > >>>> > >>>---------------------------------------------------------------------- > >>> > >>>>>-- > >>>>> > >>>> > >>>>============================================================== > >>>>============= > >>>>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". > >>> > >> > >>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". > > > > =========================================================================== > 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".
