On Thursday 14 February 2013 10:51 PM, David M. Lloyd wrote:
> 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.
In the usecase we have with SIP Servlets, the one (sip servlet app) who
instantiates and submit the
task is aware of the context that need to be propagated to its
container. It is difficult for the container
alone to find the right context.
Lets say that SIP Servlets figure out a mechanism for the application to
specify such a context,
would a SIP Servlet Container be able to run the task which has that
context, with appropriate locking?
Is that sensible from the point of view of JSR 236? Or do you expect all
the tasks to be executed
by an executor which is mostly independent of individual technology
containers?
If you folks think that it is okay for SIP Servlet specification to
leverage JSR 236 for this purpose,
then how SIP container work with JSR 236 implementation in an
application server, to achieve the same
gets reduced to a question about implementation.
thanks,
Binod.
>
> 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
>