JSR-236 has only been a half-hearted attempt at bringing asynchronous operations to the wider Java EE context, leaving many gaps or even specification bugs depending on how you see it. As of now the Concurrency Utilities for Java EE specification remains closed for Java EE 8.
One of the more painful omissions being the rather ambiguously defined CDI context propagation.
2.3.2.1 Tasks and Contexts and Dependency Injection (CDI)
CDI beans can be used as tasks. Such tasks could make use of injection if they are themselves components or
are created dynamically using various CDI APIs. However, application developers should be aware of the
following when using CDI beans as tasks:
- Tasks that are submitted to a managed instance of ExecutorService may still be running after the
lifecycle of the submitting component. Therefore, CDI beans with a scope of @RequestScoped,
@SessionScoped, or @ConversationScoped are not recommended to use as tasks as it cannot be guaranteed
that the tasks will complete before the CDI context is destroyed.- CDI beans with a scope of @ApplicationScoped or @Dependent can be used as tasks. However, it is still
possible that the task could be running beyond the lifecycle of the submitting component, such as when
the component is destroyed.- The transitive closure of CDI beans that are injected into tasks should follow the above guidelines
regarding their scopes.
This specification leaves a lot of room for interpretation. The current consensus is that the spawning thread’s request, session and conversation contexts are not propagated to the asynchronous process. Furthermore the request context is not even activated for the asynchronous operation (see discussion “inheritance of CDI scopes” for more details).
This is a rather sad state of affairs which could be reconciled by reopening the Concurrency Utilities specification for Java EE 8.
Luckily there is a very active community around Java EE; Romain Manni-Bucau added several concurrency features to DeltaSpike:
- @Locked – concurrent access control interceptor.
- @Futureable– essentially @Asynchronous for CDI.
- @Throttled – implementing @MaxConcurrency in CDI, which was proposed back in 2011 for EJB.
David Blevins implemented @TimerScoped, in Tomitriebe’s Mircoscoped API, a context across multiple timer executions.
- @TimerScoped – keep state between EJB Timer firing by using a scope to remember where you left off last time the timer fired.
Implementing these as part of extension Libraries is a good first move, however these should really become part of the Java EE specification, especially since the ambiguities in the Concurrency and CDI specification cannot be remedied from the outside.
There are many more functions that would make a highly welcome addition in the wider Java EE context (outside of EJB’s).
- @Scheduled
- @Timer
Additional scopes allowing for better asynchronous processing:
- @AsynchronousScoped – context shared across asynchronous processes spawned within a request.
- @ThreadScoped – context for the current thread.
Where to go from here
All these features and many more should be included in the Concurrency Utilities for Java EE specification. To get things rolling I would like to call out to all parties interested to gather relevant features.
Many of these missing features can be implemented in J3E Utilities API, with the aim of getting them standardized as part of the JCP specification.
How to help:
- join the J3E Concurrency Google Group.
- help with the J3E Concurrency API implementation on GitHub.
One thought on “Pushing ahead on Concurrency for Java EE 8”