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".
