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_
> <../../../javax/enterprise/concurrent/ManagedExecutorService.html>using the
> submitmethods and will be invoked when the state of the _Future_
> <http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html?is-external=true>changes
> 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 <arun.p.gupta_at_oracle.com>
> To: users_at_concurrency-ee-spec.java.net
> 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_
> <../../../javax/enterprise/concurrent/ManagedExecutorService.html>using the
> submitmethods and will be invoked when the state of the _Future_
> <http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html?is-external=true>changes
>
> 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_
>