The key point here is that when you throw an EJBException the client will receive a RemoteException - removing the benefits of throwing the exception imo.
cheers dim ----- Original Message ----- From: "Bob Lee" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 19, 2002 6:47 AM 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".
