Hi Binod,
> Or do you expect all the tasks to be executed
> by an executor which is mostly independent of individual technology
> containers?
From JSR 236 standpoint, a task is simply a Runnable or Callable with
some context setup requirements. Perhaps I did not fully understand your
question. Could you please clarify?
Regards
Anthony
On 2/15/13 2:38 AM, Binod wrote:
> 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
>>
>