jsr236-experts@concurrency-ee-spec.java.net

[jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead

From: David M. Lloyd <david.lloyd_at_redhat.com>
Date: Thu, 14 Feb 2013 11:21:02 -0600

On 02/14/2013 09:44 AM, Binod wrote:
> On Tuesday 12 February 2013 06:25 PM, frowe_at_us.ibm.com wrote:
>> I agree with David that unless there is some other usercase which
>> cannot be addressed by storing info (like ContextHints) on the
>> Runnable, the additional API is not necessary.
> I think, the usecase has come down to the following question.
>
> When a task is submitted, is it possible for ManagedExecutorService
> to handover the task to a container (eg: SIP container) for executing
> the task?
>
> The container may choose to enforce certain locking semantics based on
> some additional contextual information (like the SipApplicationSession)
>
> What would be the recommendation from
> this EG for achieving the same?

I think what you're describing is the need for a generalized API for
capturing and mutating execution context, and then selectively
propagating some or all of that context to a managed executor so that
container services have access to it?

This is a tricky problem, but I think that wrapping Runnables with
proxies probably isn't the right solution (it would only be useful in
cases where the one who is instantiating and/or submitting the task is
aware of what context needs to be propagated). Consider
container-managed context like transactions, security, and component
association, and any other container-specific context or
framework-specific context.

A good solution to this problem would have the following characteristics
(and probably many others as well):

* The container and user components would be able to use the same mechanism
* The task creator or submitter would not have to directly worry about
choosing what context to propagate
* Any party which defines or uses a propagated context type should be
isolated from other parties who do so (i.e. users should not be able to
tamper with component-defined context)
* All cross-boundary invocations in the container should have
well-defined context propagation semantics
* Relatedly, all defined context types should define how/if they are
propagated across cross-boundary invocations of various color

-- 
- DML