Using CDI with Java EE Concurrency Utilities

This blog post explores usage of CDI along with Java EE Concurrency Utilities – specifically using CDI beans as managed tasks. Here is the sample application on Github

Lets begin with a quick overview

Java EE Concurrency Utilities provides APIs and constructs to manage concurrency within Java EE applications. Many of the Java EE components have specific concurrency semantics e.g. EJBs, JAX-RS resources, WebSocket endpoints etc. Writing components with custom concurrency properties was traditionally difficult since starting unmanaged threads in a Java EE container was forbidden i.e. one was not able to leverage Java SE concurrency libraries. With Concurrency Utilities, Java EE applications have access to Managed versions of the Java SE counterparts, namely,

  • ManagedExecutorSevice
  • ManagedScheduledExecutorSevice
  • ManagedThreadFactory

.. and a bunch of other APIs as well, but the above ones are the Java EE equivalent of the Java SE concurrency APIs

Tasks as CDI beans

Both ManagedExecutorSevice and ManagedScheduledExecutorService can accept tasks to execute (in a container managed thread pool) in the form of Runnable and Callable instances. The good thing is that these tasks can be CDI beans as well. Points worth noting are

  • these CDI beans can be injected into other components as well as inject other beans
  • the scope of the CDI beans which can be used as tasks as restricted to @ApplicationScoped and @Dependent (for details read section 2.3.2.1 of the specification)

Here is a summary of ..

.. what’s going on in the application. For more details, refer to the the README and explore the code

  • Tasks are POSTED via a REST interface and the client gets back a HTTP 202 (Accepted) in response along with a task id
  • the BackgroundTask (CDI bean) is executed in a background thread by the ManagedExecutorService  – it is injected (@Inject) and a different instance is created on every invocation since the CDI bean is marked @Dependent and the JAX-RS resource is created on each request by the client
  • the status is store in a @Singleton EJB (TaskStore) – this is injected in the BackgroundTask CDI bean
  • status of each task (in progress, failed, completed) can be tracked via a REST interface by querying against a task ID
  • one can also get the status of all tasks

Further reading

Cheers!

Advertisements

About Abhishek

Java EE & distributed systems junkie who frequently blogs at abhirockzz.wordpress.com as well as simplydistributed.wordpress.com. Oh, I have also authored a few (mini) books, articles, Refcards etc. :-)
This entry was posted in Java, Java EE and tagged , , , , , , . Bookmark the permalink.

4 Responses to Using CDI with Java EE Concurrency Utilities

  1. tronski says:

    Hi Abishek, a question about the code, namely TasksResource.postTask(). Why did you use an asynchronous response there?

    Like

    • Abhishek says:

      That’s because the goal is not to block the client. It can just post/fire the (hypothetical) job/task, get an id in return and then track its progress. The background job is based on a CDI bean and Java EE Concurrency Utilities provides the necessary infrastructure (thread pool etc.)

      Like

      • tronski says:

        Ok I understand the intention, but in this particular case, the method postTask() wouldn’t really block the client even with an ordinary synchronous response because all statements return immediately, right? After all, the submit() leads to the actual asynchronous processing of the task.

        Like

      • Abhishek says:

        Yes. You’re right. In this case, it won’t matter. Also, in a previous implementation, I was trying to return unique task ID from within the background task i.e. I wanted to leverage AsyncResponse#resume from within the background task (and some other state as well). But I could not get that working due to restriction of CDI in context of Java EE Conc Utils.. so the long story short, the AsyncReponse has been there due to some past attempt 🙂 and also for the hypothetical scenario I previously pointed out

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s