I'm re-sending my email because it seems I forgot to copy Binod.
From: Nathan Rauh/Rochester/IBM
To: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 01/23/2013 01:50 PM
Subject: Re: [jsr236-experts] Re: New ContextService API proposal
from JSR 359 spec lead
Binod,
When you state "The ContextHint is a way for the application to provide a
hint to the container about the task execution strategy" -- that's
exactly what execution properties are intended for. So I want to ensure
that we are making execution properties flexible enough to achieve what
you are trying to do here, and that we don't add a duplicate mechanism
that does essentially the same thing.
I also want to make sure that hints/properties supplied to ContextService
is really the best way to go about solving the problem you are trying to
address.
Could you provide some specific scenarios showing how SIP would take
advantage of ContextService, including who is invoking these operations on
ContextService, and where they get the SipSession/SipApplicationSession
from, and what it is needing to run with context, and which other context
(if any) besides SIP should be available to the contextual proxy, and how
it will use the SipSession/SipApplicationSession that are being propagated
to it?
Without knowing very much about SIP, I have to wonder if there ought to be
a type of thread context for SIP session along the lines of security,
classloader, or naming, where context propagation can be done more
automatically by the container.
For example, with classloader context, the application doesn't need to set
its own classloader into the execution properties. The container just
automatically makes sure the contextual task runs with the class loader of
the application that created the contextual proxy. So I'd like to ask if
a similar model makes sense here. Is the
SipSession/SipApplicationSession already present in some way on the thread
where ContextService.createContextualProxy is requested from? And does
the code that's being contextualized have some way of accessing the
session or session info from the thread? If I go looking through the
APIs, I see a SipServletRequest.getSession() method that seems to return
the session. Is the goal here just to make SipServletRequest.getSession()
or other methods like it return the correct session when running from the
contextual proxy?
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: Binod <binod.pg_at_oracle.com>
To: Nathan Rauh/Rochester/IBM_at_IBMUS
Cc: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 01/22/2013 09:48 PM
Subject: [jsr236-experts] Re: New ContextService API proposal from
JSR 359 spec lead
The case we (JSR 359 EG) have is not "only" to pass a contextual
information
from application to the task/callable/runnable. The ContextHint is a way
for
the application to provide a hint to the container about the task
execution strategy.
Specifically, the ContainerSpecificContextObject can be a "SipSession" or
a
"SipApplicationSession". When the container receives this object as
the hint, it should select a locking strategy such that there is no
concurrent execution of tasks for that ContainerSpecificContextObject.
So, for the usecases, we have been thinking about, the ContextHint may
not be serializable and the lifecycle management of the ContextHint is
upto the specific container that know about it.
BTW, ContextHint mechanism is just a suggestion. I am open to any
mechanism that help us utilizing JSR 236.
thanks,
Binod.
On Wednesday 23 January 2013 01:30 AM, Nathan Rauh wrote:
Anthony/Binod,
I'm not sure I see the need for a new method that adds a ContextHint
capability. Execution properties should already allow for this, apart
from the requirement that execution properties always be String values
whereas the ContextHint in the example has some other custom type (
ContainerSpecificContextObject).
Here's an example with the existing ContextService interfaces,
Map<String, String> hints =
Collections.singletonMap("com.mycompany.hints.MY_HINT_1", hint);
Runnable rProxy = ctxService.createContextualProxy(myRunnableInstance,
hints, Runnable.class);
Future f = execSvc.submit(rProxy);
...
hint =
ctxService.getExecutionProperties(myRunnableInstance).get("com.mycompany.hints.MY_HINT_1");
I would be open to allowing data types other than String from execution
properties, provided those other types are serializable types defined in
Java SE and deserializable from any classloader. But I'm hesitant to
allow just any type to be stored as an execution property (or ContextHint)
because contextual proxies must be able to serialize/deserialize properly,
which means knowing the correct classloader of everything that serializes
along with it.
So I'm curious to learn more about what the "
ContainerSpecificContextObject" is.
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: Anthony Lai <anthony.lai_at_oracle.com>
To: jsr236-experts_at_concurrency-ee-spec.java.net
Cc: Binod <binod.pg_at_oracle.com>
Date: 01/22/2013 01:07 PM
Subject: [jsr236-experts] New ContextService API proposal from JSR
359 spec lead
Dear Experts,
Binod, the spec lead for JSR 359 - SIP Servlet 2.0, is proposing a new API
in ContextService to pass in application-provided information that can be
retrieved in the thread that executes the task.
Forwarding Binod's suggestion:
<quote>
It is possible for some containers to build contextual object based
on application provided information. For example, a container could
support
thread safe execution of the tasks based on a specific contextual
information.
<T> T createContextualProxy(T instance, Properties
executionProperties, Class<T> intf, ContextHint<C> hint)
Object getContextHint(Object contextObject)
/** Context hint information that contains the container specific
object. **/
interface ContextHint<C> {
void setHint(C hint);
C getHint();
}
Example code:
public class MyRunnable implements Runnable {
public void run() {
System.out.println("MyRunnable.run with Container Context
available.");
ContextService ctxService = (ContextService) ctx
.lookup("java:comp/env/concurrent/ContainerSpecificContextService");
ContainerSpecificContextObject object =
ctxService.getContextHint(this);
}
}
InitialContext ctx = new InitialContext();
ManagedExecutorService mes = (ManagedExecutorService)
ctx.lookup("java:comp/env/concurrent/ContainerThreadPool");
ContextService ctxService = (ContextService) ctx
.lookup("java:comp/env/concurrent/ContainerSpecificContextService");
MyRunnable myRunnableInstance = ...;
ContextHint<ContainerSpecificContextObject> hint = new
MyContextHint<ContainerSpecificContextObject>(...);
Runnable rProxy = ctxService.createContextualProxy(myRunnableInstance,
Runnable.class, hint);
Future f = mes.submit(rProxy);
</unquote>
Any comments are welcome.
Regards
Anthony