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 <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 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