The EJB 3.1 specification states:
4.5.3 Transactions:
Client transaction context does not propagate with an asynchronous
method invocation. From the Bean
Developer’s view, there is never a transaction context flowing in from
the client.
Can someone explain the design philosophy behind this?
- Is it to prevent EJB users to run into nasty concurrency/locking
bugs?
- Is it because other JavaEE specifications (eg JPA) assume a
single-threaded model.
- Is it because transaction timeouts cannot be easily monitored in an
async context?
- Is it simply to reduce complexity for the container implementations
But in a case that an EJB user would like to fasten a business method
by doing some work in asynchronously (perhaps on an XA transaction) ,
what are the options?
Will there be new reflections about this point to extend the current
specification?
Best regards
Willem Salembier