Tag Archives: concurrency

Pushing ahead on Concurrency for Java EE 8

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

JSR-236 Concurrency Utilities for Java EE Version 1.0 FR

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).
Continue reading Pushing ahead on Concurrency for Java EE 8

Synchronizing access to CDI Conversations

If you are using CDI’s conversations you will most likely have come across the dreaded BusyConversationException. The CDI 1.0 specification states that the container must ensure that only one request at a time may be associated with the conversation by blocking or rejecting subsequent requests.

OpenWebBeans will immediately reassign and throw a BusyConversationException if the conversation is currently held by another request. Weld on the other hand uses a 1 second timeout to obtain a lock on the conversation before reassigning the request and throwing a BusyConversationException. Although this makes it less likely to occur, if you are dealing with multiple waiting requests or long running processes, you will still encounter them.
Continue reading Synchronizing access to CDI Conversations