Tag Archives: EJB

Concurrency Control for CDI

At the moment there is no standard concurrency control mechanism for CDI managed beans, and at the time of writing it has not been taken into consideration for CDI 2.0 specification either.

The lack of any container based concurrency control, can lead to issues when working with unprotected contexts such as Application- or Session-Scoped beans.

Unlike EJB’s, where the container handles concurrency control, CDI only defines concurrency control for the conversation context.

The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.BusyConversationException from the restore view phase of the JSF lifecycle. The application may handle this exception using the JSF ExceptionHandler.
Conversation context lifecycle in Java EE – CDI Spec

Aside from this concurrency is only mentioned in conjunction with CDI EJB interaction.

Whilst all other relevant normal scoped contexts (Application- and Session- Scoped) are completely unguarded, the specification only defines a non adaptable concurrency control for conversation scoped beans. In my previous post on sychronizing access to CDI Conversations, I described how some of these limitation can be overcome.
Continue reading Concurrency Control for CDI

Push notifications with JEE 6

For most modern webapps push notifications have become a standard requirement. WebSockets would be my first choice, however it has only become available with JEE 7. It will take some time until JEE 7 compliant servers reach main stream production environments.

In the mean time we can achieve similar behavior with Servlet 3.0, which has become part of the JEE 6 specification, either by polling or long polling.

Polling relies on the client repeatedly sending requests to the server, polling for new messages. This will often result in empty responses, to avoid this unnecessary traffic we can hold on to the request until a new message is available or time-out is reached (long polling).

Effectively long polling requires the client to send a request, which is kept alive by the server until a response is available or a time out occurs. It is up to the client to initiate another request in both cases.

To do this we have to accept incoming GET requests and set asyncSupported to true. This stops the response object from being committed on method exit.
Continue reading Push notifications with JEE 6