Skip to main content

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

  • From: Anthony Lai < >
  • To:
  • Subject: [jsr236-spec users] [jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead
  • Date: Thu, 21 Feb 2013 16:00:51 -0800
  • List-id: <jsr236-experts.concurrency-ee-spec.java.net>

As far as I can tell, the JSR 236 spec does not prevent defining such special purpose ManagedExecutorService.

Does anyone see any issues with Binod's approach?

Regards
Anthony

On 2/21/13 8:35 AM, Binod wrote:
Hi Anthony,

Sorry for the delay. I was discussing with SIP Servlet EG on the possibilities.

One way to handle the concurrency issue is by using the thread pool
of the SIP Servlet Container to run the tasks. So, if the SIP Servlet spec
defines that a JSR 236 ManagedExecutorService
(and a ManagedScheduledExecutorService) will be made available to
the SIP Servlet applications (using the standard JSR 236 lookup mechanism)
and the submitted tasks will be executed by SIP Servlet Container using
its thread pool, then the concurrency can be handled by the SIP container.

The question is, whether this is okay from a JSR 236 spec perspective?

If it is okay, SIP Servlet Spec will specify some way to pass the correct
sip application session contexts to the container/task. It may be done
by passing sip application session id (not the session itself) in the context
service properties.

thanks,
Binod.

On Monday 18 February 2013 11:09 PM, Anthony Lai wrote:
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, 

 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







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

David M. Lloyd 02/12/2013

<Possible follow-up(s)>

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

frowe 02/12/2013

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

Binod 02/14/2013

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

Binod 02/14/2013

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

David M. Lloyd 02/14/2013

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

Binod 02/15/2013

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

Anthony Lai 02/18/2013

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

Binod 02/21/2013

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

Anthony Lai 02/22/2013

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

Frederick W Rowe 02/27/2013
 
 
Close
loading
Please Confirm
Close