Skip to main content

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

  • From: Nathan Rauh < >
  • To:
  • Subject: [jsr236-spec users] [jsr236-experts] Re: Some feedback for discussion
  • Date: Wed, 6 Feb 2013 16:33:27 -0600
  • List-id: <jsr236-experts.concurrency-ee-spec.java.net>

Anthony,

Thanks - all of your proposed changes sound good.

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:        02/06/2013 03:36 PM
Subject:        [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