Binod,
ManagedScheduledExecutorService inherits from ManagedExecutorService, so a
ManagedScheduledExecutorService is also a ManagedExecutorService and can
be used as both. You don't necessarily need two different JNDI names.
While it's true that a resource-ref to vendor-specific jndiName approach
doesn't break portability, it does make necessary a manual step for a
deployer to bind all of these resource references. A step which the
deployer could get wrong and mistakenly map to a different
Managed[Scheduled]ExecutorService instance that completely ignores the
SIP-specific execution property, causing concurrency to not be restricted
to a single task using a particular SIP session at a time as you have
asked for. That manual step, and the risk that comes with it, could be
avoided, in a portable manner, if this instance, in a manner similar to
the default instances provided by the container, had a default JNDI name,
with which applications could then do something like,
@Resource(lookup="java:comp/SIPManagedScheduledExecutorService")
ManagedScheduledExecutorService sipExecutor;
making it explicit that the application requires the SIP
Managed[Scheduled]ExecutorService, and making it unnecessary for any
manual intervention by the deployer.
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: binod pg <binod.pg_at_oracle.com>
To: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 03/07/2013 05:57 AM
Subject: [jsr236-experts] Re: New ContextService API proposal from
JSR 359 spec lead
Even the resource-ref/component specific JNDI name approach doesn't
break portability.
Also, I was hoping that the duty of restricting the number of MES is
with the product
rather than the specification.
In any case, SIP will need to define two JNDI names, right? One for
ManagedExecutorService
and another for ManagedScheduledExecutorService.
thanks,
Binod.
On 3/7/2013 4:15 AM, frowe_at_us.ibm.com wrote:
> Absolutely, there are two reasons. One, it allows for portability but
> more importantly, configuration by exception. In other words, if my
> SIP application needs to lookup the SIP-specific MES, I can expect to
> find it at the proscribed location in JNDI, if its not there, there's a
> problem.
> Two, there is a single jndi name because there is a single SIP-specific
> MES. The intent of JSR236 was not to proliferate instances of MES in
> the appserver as it makes it difficult to centrally manage thread
> pooling.