users@concurrency-ee-spec.java.net

[jsr236-spec users] Feedback on PR

From: Arun Gupta <arun.p.gupta_at_oracle.com>
Date: Sat, 09 Feb 2013 11:01:43 +0100

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