Skip to main content

[jsr236-spec users] [jsr236-experts] Re: Re: Some feedback for discussion

  • From: Frederick W Rowe < >
  • To:
  • Subject: [jsr236-spec users] [jsr236-experts] Re: Re: Some feedback for discussion
  • Date: Thu, 7 Feb 2013 08:30:45 -0500
  • List-id: <jsr236-experts.concurrency-ee-spec.java.net>

Anthony,

Your proposed changes look good.

Regards,

Fred Rowe

WebSphere Architect
Senior Software Engineer
IBM Software Group




Anthony Lai 
< >
 
02/06/2013 04:36 PM
Please respond to
jsr236-experts


To

cc

Subject
[jsr236-spec users] [jsr236-experts] Re: Some feedback for discussion






Hi Nathan,

This is fine. This has the advantage of allowing the caller to have more 
control of what types of context to be propagated to the thread that 
invokes the ManagedTaskListener methods.

If everyone agrees with the removal of CONTEXTUAL_CALLBACK, section 2.3.1 
of the spec could be changed from:

By default, it is not required that container context be propagated to the 
threads that invoke these methods. This is to avoid the overhead of 
setting up the container context when it may not be needed in these 
callback methods. Java EE Product Providers may provide configuration 
option  in ManagedExecutorService and ManagedScheduledExecutorService to 
make these callback methods contextual invocation points. See sections 
3.1.4.1 and 3.2.4.1. Execution property CONTEXTUAL_CALLBACK_HINT in 
ManagedTask can also be used to request these callback methods to become 
contextual. 
Other callback methods run with an unspecified context, but can be made 
contextual through the ContextService (see following sections), which can 
make any Java object contextual. 

to:

It is not required that container context be propagated to the threads 
that invoke these methods. This is to avoid the overhead of setting up the 
container context when it may not be needed in these callback methods. 
These methods can be made contextual through the ContextService (see 
following sections), which can make any Java object contextual. 

and all references to the attribute Contextual-Callback will be removed.

Regarding other issues that I raised in my earlier mail:
1) null interfaces to createContextualProxy
- It is probably not very useful to allow returning a contextual proxy 
object that does not implements any interfaces, which would have no proxy 
method to invoke. So given the choices between this or throwing 
IllegalStateException, I would prefer throwing exception and the javadoc 
for the methods could be updated to reflect this change:

IllegalArgumentException - - if the interfaces argument is null, the 
instance does not implement all the specified interfaces or there is not 
an accessible default constructor.

2) Will be renaming USE_PARENT_TRANSACTION to USE_CALLER_TRANSACTION

3) Renaming CONTEXTUAL_CALLBACK_HINT to CONTEXTUAL_CALLBACK
Non-issue since we will be removing the property.

4) ManagedTaskListener: Consider passing the task to methods of 
ManagedTaskListener. 
Proposed changes to the ManagedTaskListener APIs with addition argument 
for the task that was originally submitted:

void taskSubmitted(Future<?> future, ManagedExecutorService executor, 
Object task)

void taskAborted(Future<?> future, ManagedExecutorService executor, Object 
task, Throwable exception)

void taskDone(Future<?> future, ManagedExecutorService executor, Object 
task, Throwable exception)

void taskStarting(Future<?> future, ManagedExecutorService executor, 
Object task)

task - the task that was submitted

5) Should we use annotations instead of executionProperties?
Not making any changes for this issue.

6) use CDI Events mechanism with using @Observes instead of 
ManagedTaskListener interface
No feedback on this issue yet.
 
Regards
Anthony

On 2/6/13 11:27 AM, Nathan Rauh wrote:
Sorry to bring this up so late, but it just occurred to me that 
CONTEXTUAL_CALLBACK is redundant with capability that's already available 
in JSR 236. 
In the case where a user wants to guarantee that methods of 
ManagedTaskListener or Trigger will run with context of the task 
submitter, they can accomplish the same via ContextService, 
For example, 

contextualListener = 
contextService.createContextualProxy(ManagedTaskListener.class, listener); 

contextualRunnable = ManagedExecutors.managedTask(runnable, 
contextualListener); 
managedExecutorService.submit(contextualRunnable); 

So we don't necessarily need a CONTEXTUAL_CALLBACK or @Contextual at all. 

Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802 



From:        Nathan Rauh/Rochester/IBM 
To:        

 
Date:        01/31/2013 04:01 PM 
Subject:        Re: [jsr236-experts] Some feedback for discussion 


Anthony, 

Here are my comments, 

1) clarify the behavior when no interfaces is passed in to the 
createContextualProxy APIs that takes "Class<?>... interfaces" 
I agree it would be good to clarify. 
Here's a third option to consider -  ContextService.createContextualProxy 
should be consistent with the behavior of java.lang.reflect.Proxy, on 
which it is also possible to invoke 
    Proxy.getProxyClass(ClassLoader, interfaces...) 
and 
    Proxy.newProxyInstance(ClassLoader, interfaces, handler) 
without any interfaces.  In both cases, it appears that. 
java.lang.reflect.Proxy just returns a proxy class or proxy that doesn't 
implement any interfaces. So, ContextService.createContextualProxy could 
do the same. 
Otherwise, I'd vote for (b) IllegalArgumentException 

2. I'm fine with renaming to  USE_CALLER_TRANSACTION to make it clearer 

3. I'm also fine with renaming to CONTEXTUAL_CALLBACK, and with the 
JavaDoc updates to clarify 

4. ManagedTaskListener: Consider passing the task to methods of 
ManagedTaskListener. This sounds like it might be convenient, but if we do 
it, I'd prefer we add the task as its own parameter rather than  change 
the first argument in the methods from Future to FutureTask.  I'm not so 
comfortable with FutureTask here, because it creates some confusion about 
whether or not the FutureTask, if re-submitted, would inherit the 
ManagedTaskListener and execution properties of the original task (for 
example, would the FutureTask be a ManagedTask?).  It also seems likely 
that a user might want to cast back to their own task interface, and 
FutureTask makes that impossible. 

5. Should we use annotations instead of executionProperties?  I would say 
no, because annotations don't fit very well with a number of usage 
patterns.  For example, I should be able to submit any generic Runnable or 
Callable (it might even be from another vendor) with execution properties. 
 I should be able to use managedExecutorService.invokeAll to submit 
multiple tasks at once, each with their own different execution 
properties.  I should be able to write portable applications that include 
vendor-specific execution properties from multiple application server 
vendors.  It's not clear to me where annotations would go that would cover 
all of these scenarios.   I can see how @Contextual on ManagedTaskListener 
and Trigger would make sense rather than having CONTEXTUAL_CALLBACK as an 
execution property (and so I'm fine with just that), but I don't see how 
the other execution properties could be annotations and still preserve all 
the functionality that you get with the spec as currently written. 


Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802 




From:        Anthony Lai 
< >
 
To:        

 
Date:        01/31/2013 01:13 PM 
Subject:        [jsr236-experts] Some feedback for discussion 



Dear Experts,

I have received some feedback about the spec and the APIs. Please let me 
know what your opinions are on these 6 items.

1. ContextService: To clarify the behavior when no interfaces is passed in 
to the createContextualProxy APIs that takes "Class<?>... interfaces" as 
one of the arguments
- We could either 
  - a) treat this as legal and the ContextService implementation would 
find out the what interfaces that the object to have proxy created 
implements, or
  - b) throws exception, possibly IllegalArgumentException


2. ContextService: The name USE_PARENT_TRANSACTION is confusing. Consider 
renaming to USE_CALLER_TRANSACTION
- This property is intended to run the proxy method under the same 
transaction on the thread of the caller who invokes the proxy method to be 
run on the same thread. The name USE_PARENT_TRANSACTION could lead users 
to think that the proxy method would be invoked under the transaction of 
the thread where the contextual proxy method was created.


3. ManagedTask: Consider renaming CONTEXTUAL_CALLBACK_HINT to 
CONTEXTUAL_CALLBACK
- Reason being Java EE container are required to make the callback 
contextual if this property is set to "true" for a submitted task. Having 
"HINT" in the property name suggests that the Java EE container can choose 
not to make the callback contextual.

- The javadoc for CONTEXTUAL_CALLBACK property would be
Execution property to be returned in getExecutionProperties() or 
ContextService.createContextualProxy() to inform the Java EE Product 
Provider about whether the methods inManagedTaskListener and Trigger 
associated with this task needs to be called under the same context as the 
task. Any values other than "true" means the methods will be run with 
unspecified context.


4. ManagedTaskListener: Consider passing the task to methods of 
ManagedTaskListener
- The idea is to allow the applications to resubmit the task from 
ManagedTaskListener methods. ManagedTaskListener methods already passed in 
ManagedExecutorService as one of the arguments.
- If we agree that this is a good idea, one possibility is to change the 
first argument in the methods from Future to FutureTask.


5. Should we use annotations instead of executionProperties?
- For example, instead of using LONGRUNNING_HINT="true" and 
IDENTITY_NAME="some description", a task can be annotated with something 
like @LongRunning and @IdentityName(value="some description")
- CONTEXTUAL_CALLBACK[_HINT] would become an annotation for the 
ManagedTaskListener implementation. For example @Contextual.


6. There is also a suggestion to use CDI Events mechanism with using 
@Observes instead of ManagedTaskListener interface for getting notified of 
task submission lifecycle callback.

Comments are welcome.

Regards
Anthony 




[jsr236-spec users] [jsr236-experts] Re: Some feedback for discussion

Nathan Rauh 02/06/2013

[jsr236-spec users] [jsr236-experts] Re: Some feedback for discussion

Anthony Lai 02/06/2013

[jsr236-spec users] [jsr236-experts] Re: Some feedback for discussion

Nathan Rauh 02/06/2013

[jsr236-spec users] [jsr236-experts] Re: Re: Some feedback for discussion

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