Yes, I agree that the programmer must be able to control commit/rollback.
But as a default option, I would like to delegate it to the container, based
on a simple strategy:
Exception = Rollback
No Exception = Commit
The strategy of the EJB spec is:
(Application) Exception = Commit
No Exception = Commit
I claim that the strategy of EJB 1.1. fits less than 1% of all applications.
When I need to override the default behaviour, I can catch the exception in
my EJB, and setRollbackOnly(false).
It wouldn't put any restrictions on the programmer's possibilities to
control transactions. The current spec puts a serious restriction on
component reuse: You can not (always) aggregate components out of existing
components. If you develop a component to be usable from a client, you must
code your transaction semantics (call setRollbackOnly(true) in case of an
application exception) into that component. If another component need to
aggregate the existing component (reuse), it can not control the transaction
management, since the existing component already takes a decision down the
line (e.g. calls setRollbackOnly(true) in case of an application exception).
Aggregating components is a fairly common scenario when developing message
driven beans. Components that process (inbound) asynchronous
inter-application messages, are often more coarse-grained than components
servicing synchronous clients.
/Johan
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Prabhakar Goel
Sent: den 28 april 2001 13:33
To: [EMAIL PROTECTED]
Subject: Re: Rollback in CMT
probably it is assumed that any user specific or say application specific
Exception is thrown by a programmer for known reason so he can make commit
or rollback in " <your-own>Exception " as and if required but Programmer's
are not given the flexibility to throw RemoteException(instead have to
throw EJBException) and only Container can throw it so in that case
rollback is Containers job and not Programmers.
***********************
enJoy Life with Technology
***********************
pirbhu
"Johan Eltes"
<johan.eltes@callista To: "krithikav"
<[EMAIL PROTECTED]>,
.se> <[EMAIL PROTECTED]>
Sent by: cc:
owner-ejb-interest@ja Subject: RE: Rollback
in CMT
va.sun.com
04/26/01 09:33 PM
This is kind of hard to...
1) ...understand by reading the spec
2) ...to motivate
...but it conforms to EJB 1.1.
Runtime exception originating from application code -> Container rollback
None-runtime exceptions originating from application code -> Container
commits.
So far, I haven't found one single situation, when I would like an
exception
to commit a transaction. Does someone have an idea about the rational of
this behaviour (the transactional semantics for application exceptions)?
Just to avoid misunderstanding:
A RemoteException is not a runtime exception, but it has special treatment
by the container. If you derive an exception from RemoteException, I
suppose
your container classifies it as any application exception. The EJB 1.1.
spec
recommends you to throw EJBException, instead of remote exception.
/Johan
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of krithikav
Sent: den 26 april 2001 16:56
To: [EMAIL PROTECTED]
Subject: Rollback in CMT
Importance: High
Hi,
When I throw a remoteexception from my EJB which has Container Managed
Transaction, the
container rollsback the database updates. However if I derive an Exception
class from the
RemoteException and throw the same from my EJB, the container does not
rollback the transaction. Why is this so? Or am I making some mistake?
Regards,
Krithika
===========================================================================
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".
