Richard,
I don't see the problem in the EJB-spec. If I understand it, there a three ways to
start a
transaction.
A client starting a transaction still keep control over it's transaction through the
UserTransaction interface. It is the only instance allowed to terminate that
transaction. So
if an application exception occur, the client can still hask for the transaction
status.
That's what Vlada says.
A container managed transaction isn't interesting for the client. A received
application
exception always means the transaction has been rolled back by the container. Since the
container always terminate that transaction at the end of the method execution. This
also
apply for stateless session beans managing transactions since they are not allowed to
keep
transactions accross multiple calls.
Statefull sessions with bean-managed transactions may keep transactions accros method
calls.
So in front of an application exception, it will be difficult for a client to know
whether
former transactions made a part of the work persistent. But that isn't a problem since
bulding
the transaction logic in the bean code, also requires the bean client to well
understand the
bean specification (that means when a transaction is started and comited/rolled back).
That is how I understand the spec, any idea?
Regards.
Francis.
www.mathema.de
Richard Monson-Haefel wrote:
> Evan Ireland wrote:
>
> > Richard Monson-Haefel wrote:
> > >
> > > > ...
> > >
> > > This is not how the specification is worded. Referring to Table 8 of the Public
> > > Release 2, in the third row where the scope of the transaction is delimited by
>the
> > > bean method and its an application exception type:
> > >
> > > The bean can choose to invoke setRollbackOnly() before throwing an Application
> > > Exception. If this occurs, the spec says that the container must re-throw the
> > > application exception. So the client can *not* know the disposition of the
>bean's
> > > transaction. The bean should be required to throw a system exception if it
>chooses to
> > > invoke setRollbackOnly( ) otherwise there is absolutely now way for the client to
> > > determine if the transaction was successful or not.
> >
> > We went through a similar issue with some of our customers before EJB 1.0, with
> > the following result. If the bean calls setRollbackOnly() and throws an
> > application exception, it should be an application exception that is
> > 'understood' by the client to mean the transaction was rolled back.
>
> This seems reasonable to me. As Assaf Arkin pointed out to me in an e-mail on this
>topic:
> EJB dumbs-down the Tx programming model a little which makes developers a lot more
> productive, but you loose some of fine grained control and error handling that you
>get
> using a low level Tx API like OTS.
>
> --
> Richard Monson-Haefel
> EJB Expert for jGuru.com
> ( http://www.jguru.com )
>
> Author of Enterprise JavaBeans
> Published by O'Reilly & Associates
> ( http://www.ejbnow.com )
>
> ===========================================================================
> 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".
