Paul Kavanagh wrote:
Thanks for the reply Bob - great feedback. I've a few follow-up questions if you don't mind.
No problem.
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 ?
Yes, CreateException and FinderException are standard application-level
exceptions and so far as I know should be handled as such.
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.
Good point. I went ahead and looked it up in the spec., and it does use
"must". Specifically, the spec. says that the container should throw the
instance away and release any associated resources without invoking any
business or container callback methods.
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) ?
Correct. A container should wrap them in a RemoteException for rempote
clients and an EJBException for local clients. In some vendor
implementations however, you can specify that a method is "idempotent",
and the container can transparently fail over and retry an invocation
regardless of whether the first invocation completed.
I agree - I already call setRollbackOnly() before throwing an application level exception.
Thanks,
Bob
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".
