FW: [concurrency-interest] Executors and J2EE Work frameworks

David Jencks david@coredevelopers.net
Fri, 12 Dec 2003 12:39:40 -0800

I've just reviewed the J2ee Work specification proposal.  In my opinion 
it is a worthwhile effort and a good starting point, with the following 

This proposal does not even mention two critical and essential aspects 
of any j2ee proposal, namely the relationship to security and 
transaction contexts.  In contrast to the J2ee Connector Architecture 
1.5 spec, where security context propagation issues are significant and 
totally ignored, inside an application server I don't see significant 
issues with propagating a security context between threads.  However, 
there are many obvious and major issues with propagating a transaction 
context between threads, ranging from in-vm synchronization/locking 
issues to indeterminate results if two threads access a single resource 
manager within the same transaction.  The Connector 1.5 spec deals with 
these by the simple expedient of prohibiting concurrent imports of the 
same transaction.  While this solution is obviously sufficient, I'm not 
convinced that it is the only workable solution.  Anything else will 
IMO require a lot of careful thought and several implementations to 
make sure it is actually workable.

This proposal points out that the Connector 1.5 WorkManager is not 
suitable for use from a j2ee application.  IMO it is also not usually 
suitable for use from anything such as a resource adapter that wishes 
to import transactions.  The Connector 1.5 ExecutionContext requires 
specification of the Xid for the transaction to import before the work 
is submitted (section 10.3.5).  This requires the submitting thread to 
interpret the incoming data to extract the Xid.  Since this could 
involve an arbitrarily large amount of work (for instance if the xid is 
hidden inside a very large message), extracting the xid could more 
scalably be done inside the worker thread.

I would like to see this specification develop to include discussion 
and resolution of fast, scalable security and transaction context 
propagation and provide a solution to the limitations of the Connector 
1.5 work model.

Many thanks,
* David Jencks
* Partner
* Core Developers Network
* http://www.coredevelopers.net

On Thursday, December 11, 2003, at 05:29 PM, Noel J. Bergman wrote:

> Since these two JSRs were discussed here recently, I thought that there
> might be some folks who would like to comment.
> Please comment directly to concurrency-interest@altair.cs.oswego.edu.
> 	--- Noel
> -----Original Message-----
> From: concurrency-interest-admin@cs.oswego.edu
> [mailto:concurrency-interest-admin@cs.oswego.edu]On Behalf Of Doug Lea
> Sent: Thursday, December 11, 2003 20:03
> To: concurrency-interest@altair.cs.oswego.edu
> Subject: [concurrency-interest] Executors and J2EE Work frameworks
> We are still looking over integration issues with the proposed (but
> not yet accepted) J2EE Work and Timer JSRs. If you have actually used
> the BEA or IBM precursors of these proposed APIs, and have any 
> experiences
> or observations you'd like to tell us about, we'd be very happy to
> hear of them, the sooner the better.
> Again, they are at:
>   http://www.jcp.org/en/jsr/detail?id=236
>   http://www.jcp.org/en/jsr/detail?id=237
> Follow links near the bottom of each to see BEA and IBM's proposed
> APIs.
> Thanks!
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest