A very specific situation where it may be (is it really?) the only option to throw an EJBException to force a rollback, is when you want an MDB with bean managed transaction demarcation to force the message to be backed-out to the destination (and then fired again). Just as curiosity...
/johan Den 2002-12-19 12.37, skrev "Dmitri Colebatch" <[EMAIL PROTECTED]>: > 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". > ==========================================================================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".
