Skip to main content

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

  • From: Anthony Lai < >
  • To:
  • Subject: [jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES
  • Date: Wed, 19 Dec 2012 09:46:58 -0800
  • List-id: <jsr236-experts.concurrency-ee-spec.java.net>

Nathan,

Thanks!

Regarding ContextService.USE_PARENT_TRANSACTION, I am planning to rewrite the sentence to:

" This property will be ignored when the proxy object is submitted for execution asynchronously on a different thread, such as if it is specified in the execution properties of a ManagedTask which is submitted to an Executor or any of its subclasses."

I will make the other changes as suggested.

Regards
Anthony

On 12/18/12 6:43 PM, Nathan Rauh wrote:
" type="cite">Anthony,

This looks really good. Thanks for writing it all up.

I noticed a couple of minor things (mostly just typos)


This example in ManagedExecutors has a typo
   Runnable taskWithListener = ManagedExecutors.managedTask(task, myTaskListener);
   executor.submit(task);
It should be:
   Runnable taskWithListener = ManagedExecutors.managedTask(task, myTaskListener);
   executor.submit(taskWithListener);


In ContextService.createContextObject, there's a typo,
"If the application component that created the proxy is started or deployed, all methods on reflected interfaces will throw a java.lang.IllegalStateException."
It should be:
"If the application component that created the proxy is not started or deployed, all methods on reflected interfaces will throw a java.lang.IllegalStateException."


In ContextService.USE_PARENT_TRANSACTION it currently reads:
"This property will be ignored when the proxy object is submitted to an Executor..."
Contextual proxy objects typically can't be submitted to an Executor, I think you meant:
"This property will be ignored if specified on a ManagedTask that is submitted to an Executor..."


After seeing this in several places,
"ClassCastException - - thrown if one of the keys or values in the specified Properties object are not of type String."
I wonder if we could better enforce this by just switching the type from java.util.Properties to java.util.HashMap<String, String>?  I think we might have considered that before and didn't see any reason to switch it, but this extra type checking/validation now seems like a pretty good reason, since <String,String> will force the user to write it correctly to begin with.


In ManagedTask.CONTEXTUAL_CALLBACK, the text currently includes:
"If this property is not specified, container context will not be propagated to the threads that invoke the callback methods on the ManagedTaskListener."
I think we should remove this statement, in which case if not specified, the behavior can be implementation specific such that the container is free to do whatever is most optimal - not having to remove context if already there, and not having to add context if not present.  By deciding not to specify the property, the user is saying that their implementation doesn't care one way or the other about context being available to these listener notifications, and so the container can do whatever is most convenient.



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:        12/18/2012 05:53 PM
Subject:        [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES




Thanks, Nathan!

I have update the javadoc at
http://concurrency-ee-spec.java.net/javadoc/ to capture what we have discussed so far. I have also included some minor corrections in this update. Classes that were updated includes:

ContextService
LastExecution
ManagedExecutorService
ManagedExecutors
ManagedScheduledExecutorService
ManagedTask (replacing Identifiable)
SkippedException

Regards
Anthony



On 12/18/12 12:25 PM, Nathan Rauh wrote:
I agree - affinity only makes sense at the level of the ManagedExecutorService.
At the per-task level, DISTRIBUTABLE=true/false as you suggested is 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:        
12/18/2012 12:02 PM
Subject:        
[jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES




Thanks for pointing that out. :-)

I was looking at this execution property and was wondering if
DISTRIBUTABLE_WITH_AFFINITY hint applies to a single task. It applies to
a MES or MSES so tasks submitted to the MES or MSES would be routed to
the same application server process. But what does it mean on a task?
Should a task simply provide hint saying whether it can be run in a
remote process. So instead of having:

Property name: RUN_LOCATION
Possible values: LOCAL, DISTRIBUTABLE, DISTRIBUTABLE_WITH_AFFINITY

Does it make sense to have this instead:

Property name: DISTRIBUTABLE
Possible values: "true", "false"

Regards
Anthony

On 12/18/12 7:25 AM,
"> wrote:
> I'm assuming that you'll correct the typo in
> "DISRTIBUTABLE_WITH_AFFINITY
> " when updating spec...






[jsr236-spec users] Re: [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

frowe 12/18/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Anthony Lai 12/18/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Nathan Rauh 12/18/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Anthony Lai 12/18/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Nathan Rauh 12/19/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Anthony Lai 12/19/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Nathan Rauh 12/19/2012
 
 
Close
loading
Please Confirm
Close