Skip to main content

[jsr236-spec users] [jsr236-experts] Re: Feedback on PR

  • From: Nathan Rauh < >
  • To:
  • Subject: [jsr236-spec users] [jsr236-experts] Re: Feedback on PR
  • Date: Wed, 13 Feb 2013 08:34:53 -0600
  • List-id: <jsr236-experts.concurrency-ee-spec.java.net>

Anthony,

That sounds good.  I agree with the third option not being included because we don't want it to be required.

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/12/2013 05:13 PM
Subject:        [jsr236-experts] Re: Feedback on PR




Hi Nathan,

Thanks for the suggestion. I am going to rename USE_CALLER_TRANSACTION property to TRANSACTION and move it to ManagedTask. I am proposing the javadoc for TRANSACTION execution property as:

Execution property to be returned in getExecutionProperties() or ContextService.createContextualProxy() to inform the Java EE Product Provider under which transaction should the task or proxy methods of contextual proxy objects be executed in.

Valid values are:

"SUSPEND" (the default if unspecified) - Any transaction that is currently active on the thread will be suspended and a UserTransaction (accessible in the local JNDI namespace as "java:comp/UserTransaction") will be available. The original transaction, if any was active on the thread, will be restored when the task or contextual proxy object method returns.

"USE_TRANSACTION_OF_EXECUTION_THREAD" - The contextual proxy object method will run within the transaction (if any) of the execution thread. A UserTransaction will only be available if it is also available in the execution thread (for example, when the proxies method is invoke from a Servlet or Bean Managed Transaction EJB).  When there is no existing transaction on the execution thread, such as when running tasks that are submitted to ManagedExecutorService or ManagedScheduledExecutorService, a UserTransaction will be available.


Since we do not want to include optional items into the spec, so I am not adding the value USE_TRANSACTION_OF_ORIGINAL_THREAD.

Regarding the confusion in the javadoc for ManagedTaskListener.taskDone(), how about rewriting it to:

Called when a submitted task has completed running, either successfully or failed due to any exception thrown from the task, task being cancelled, rejected or aborted.


Regards
Anthony

On 2/10/13 6:01 AM, Nathan Rauh wrote:
Arun/Anthony,

Here are some of my replies.  Some interesting points were raised.



- If a task is submitted to a ManagedExecutor from an EJB (bean-managed transaction), does it run in EJB's transaction context ?

No.

- Its clear that security context is propagated but seems like UserTransaction need to be explicitly started and rolled back/committed. Why this discrepancy ?

It's a much more complicated scenario for multiple threads to be running under the same transaction than it is for multiple threads to be running under the same security context. If we want to allow this for UserTransaction, it should be controlled with an execution property, similar to USE_CALLER_TRANSACTION.  However, this brings up a good point about future compatibility that we should address now.  If, in the future we add a second true/false execution property, we could end up with a nonsensical combination where both are set to TRUE.  Maybe it would be better to rename the USE_CALLER_TRANSACTION execution property to allow more than 2 options (and move it from ContextService to ManagedTask with the other execution properties, as it would now be applicable to ManagedExecutorService as well).

For example,
  • TRANSACTION=SUSPEND
    Suspend transaction of execution thread, if any is present there.
  • TRANSACTION=USE_TRANSACTION_OF_EXECUTION_THREAD
    Use the transaction of execution thread, if any is present there.
  • TRANSACTION=USE_TRANSACTION_OF_ORIGINAL_THREAD
    Use the transaction that was active on the original thread during the point at which context was captured (ManagedExecutorService.submit or ContextService.createContextualProxy).
It should be optional whether a container chooses to support the third option.

- ManagedTaskListener javadoc says

It can be registered with a
ManagedExecutorService using the submit methods and will be invoked when the state of the Futurechanges
This interface is implemented by a task so not sure if this statement is correct. What do you think ?
We recently fixed the spec so that ManagedTaskListener does not need to be implemented by a task.


Called when a submitted task has completed running, successful or otherwise after submitted.

How does "otherwise after submitted" different from taskSubmitted ?
I think this is just a misinterpretation and the wording needs some improvement to be more clear.  It's intending to refer to when a task has completed running - either successfully or otherwise (which could be that the task fails with an error, or was canceled, or interrupted ...)


- I see a default ManagedScheduledExecutorService is required. I think it would be useful to have a default  ManagedExecutorService as well. What do you think ?

Default ManagedExecutorService is  part of the spec.  See section 3.1.4.2.


Anyway, I'm wondering if instead of using an interface-driven approach, should something like @Schedule be used instead ? So the spec can introduce a new annotation @ManagedSchedule which can then be specified on the task implementing Runnable.run or Callable.call method. The semantics could stay similar to @Schedule.
We need to keep in mind the task submitter doesn't necessarily own the task implementation, and will be unable to modify it to include annotations.  Also in some scenarios it might be desirable to submit the same class of task twice, with different schedules, and wouldn't make sense to have the schedule information on the task itself.


Unless I'm missing some other options, the only way I can think of that annotations could be workable (for Trigger as well as execution properties as discussed on another thread) and allow for almost all of the existing usage patterns would be to require the task submitter to wrap Runnables/Callables with their own ManagedTask implementation that provides the annotations.  Even then, we would be losing the ability that Trigger provides for scheduling to be tied to custom business logic that considers other variables that can't be represented in @ManagedSchedule.



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




From:        
Arun Gupta ">< >
To:        
">
Date:        
02/09/2013 04:02 AM
Subject:        
[jsr236-spec users] Feedback on PR




Hi Anthony,

Some feedback/questions from the latest revision of the spec ...

- If a task is submitted to a ManagedExecutor from an EJB (bean-managed transaction), does it run in EJB's transaction context ?

- Its clear that security context is propagated but seems like UserTransaction need to be explicitly started and rolled back/committed. Why this discrepancy ?

- Spec says UserTransaction is only available using JNDI. It can be injected using @Resource as well. Do you want to specify that ? Currently only JNDI look up is working though.

- 3.1.8.2.1 says:

UserTransaction ut = ...;

This code needs to be a in try/catch block and generally would be initialized in the ctor or run method.

- ManagedTaskListener javadoc says


It can be registered with a
ManagedExecutorService using the submit methods and will be invoked when the state of the Futurechanges

This interface is implemented by a task so not sure if this statement is correct. What do you think ?

- ManagedTaskListener seems to be invoking "run" method only. It seems like its not fully implemented yet ?

- ManagedTaskListener.taskDone javadoc says:


Called when a submitted task has completed running, successful or otherwise after submitted.


How does "otherwise after submitted" different from taskSubmitted ?

- I see a default ManagedScheduledExecutorService is required. I think it would be useful to have a default  ManagedExecutorService as well. What do you think ?

- May be this is already there in your draft but PR of the spec does not have much discussion about Trigger.

Anyway, I'm wondering if instead of using an interface-driven approach, should something like @Schedule be used instead ? So the spec can introduce a new annotation @ManagedSchedule which can then be specified on the task implementing Runnable.run or Callable.call method. The semantics could stay similar to @Schedule.

I'll send more as I continue to grok!

Thanks,
Arun

--

http://twitter.com/arungupta
http://blogs.oracle.com/arungupta




[jsr236-spec users] Feedback on PR

Arun Gupta 02/09/2013

[jsr236-spec users] Re: Feedback on PR

Nathan Rauh 02/10/2013

[jsr236-spec users] [jsr236-experts] Re: Feedback on PR

Anthony Lai 02/12/2013

[jsr236-spec users] [jsr236-experts] Re: Feedback on PR

Nathan Rauh 02/13/2013
 
 
Close
loading
Please Confirm
Close