Francis wrote:
> Richard Monson-Haefel schrieb:
>
> > Rickard �berg wrote:
> >
> > > Hey
> > >
> > > If I have a bean FooBean which have two methods, doSomething and fooBar,
> > > of which doSomething has tx setting SUPPORTS and fooBar has REQUIRED.
> > > What happens if a client (without a tx) calls doSomething, and that
> > > method calls fooBar in the same bean? Then the fooBar method would be
> > > executed without a transaction since there is no EJBObject that is being
> > > called that can start the tx.
> > >
> > > So, is this a bad idea? (rhethoric)
> > >
> > > The workaround would be to do ctx.getEJBObject() in doSomething and call
> > > fooBar through that, which could start the tx.
> > > \
> >
> > Actually this would not work. A bean identity can not service two different tx
> > contexts. Since doSomething is executing without a tx and fooBar requires a tx,
> > an exception would occur when you executed fooBar( ) on the EJBObject returned
> > by ctx.getEJBObject() within the doSomething method. (There are also reentrant
> > considerations but that's off subject.)
> >
>
> Richard,
> (reentrant presumed), why doesn't it work? As far as I understand the EJB spec, the
> EJBObject implementation must start a new transaction for fooBar() for TX_REQUIRED
> and throw an exception for TX_MANDATORY.
> What do you understand under tx context? What's the difference betwen the tx and
> the thread context?
>
> Regards.
> --
> Francis Pouatcha
Actually this appears to be different in Session beans than Entity beans. With Session
beans the following rule applies
Enterprise JavaBeans 1.0
6.6.1 Restrictions for transactions
" If a session Bean instance is participating in a transaction, it is an error for a
client to invoke a method on the session Bean in a different or no transaction
context. It is also an error to invoke a method on the session Bean if the
deployment descriptor would cause the container to execute the method in a
different transaction context or no transaction context. The container will throw
the java.rmi.RemoteException to the client in such a case."
With Entity beans it depends on how the container implemented concurrency. According
to section 9.5 "Concurrent access from multiple transactions", a container may handle
different transaction contexts with separate beans instances (option 1) or synchronize
transactions on the same instance (option 2).
With option 1 the underlying database provides the synchronization by way of
isolation. In this case invoking a method with a different tx attribute is allowed but
may deadlock depending on the type of isolation used. If, for example, an isolation
level of TRANSACTION_SERIALIZABLE is used a deadlock will occur.
With option 2 the synchronization of concurrent requests is handled by the container by
synchronizing all requests on a single instance for a specific identity. In other
words, if Account 143 is already being accessed by a client, the instance that is
handling that request will be synchronized to handle all requests for that identity.
Concurrent requests in different tx contexts are blocked until the instance is free. In
this case a deadlock is unavoidable.
Richard
--
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".
