EJB Annotations Primer: Getting a Grip on Concurrency Semantics

Datetime:2016-08-23 01:57:10          Topic: EJB           Share

EJBs are not about XMLs & interfaces any more. From a Java EE developer standpoint, the real magic of EJBs lies in its annotation driven programming model. This is personified by its API layout which consists of 32 annotations. These are used by the the container to weave its magic at runtime. In other words, the container does all the heavy lifting for you once you communicate your requirements via annotations. It may well be worth investing some time in getting a strong grip on the practical usage of these annotations!

Abhishek Gupta  has recently published a free  book  on the topic to help you on your way, composed of a series of short chapters, each of which covers a specific part of the EJB specification. Aside from the fact it’s free, Gupta notes, it also covers the latest version (3.2) of the EJB specification with a special emphasis on its annotations. 

Here’s a short extract from the work to get you started:

Having a good understanding of the Concurrency semantics of different sessions beans is extremely important in order to be able to leverage them effectively. Let’s look at the related annotations.

@AccessTimeout

Specifies the time period after which a queued request (waiting for another thread to complete) times out. This feature does not make sense for Stateless beans since the container allocates a new bean instance for each request. This annotation is valuable for Stateful beans as well as Singleton beans configured with container managed concurrency option (ConcurrencyManagementType.CONTAINER).

You can use the value and unit elements of this annotation to refine its behaviour. Here are a few usage options

• @AccessTimeout(0) – this means that your method does not support concurrent access at all and the client would end up getting a javax.ejb.ConcurrentAccessException

• @AccessTimeout(-1) – your method will block indefinitely

• @AccessTimeout(5000) – method will wait for 5000 ms (5 seconds) before the next thread in queue (if any) if given a chance

@ConcurrencyManagement

A Singleton bean is flexible in terms of Concurrency Management – by default (convention), the container handles concurrent access to a Singleton bean. By using the @ConcurrencyManagement annotation, you as a bean developer can take the bean concurrency management into your own control. The possible values (enums) for this annotation are – ConcurrencyManagementType.CONTAINER and ConcurrencyManagementType.BEAN. The nomenclature of these enums clearly define their role. In case you opt for Bean managed concurrency, you as a bean developer are responsible for the thread safety of objects used within the Singleton bean e.g. using synchronized methods, thread safe collections, etc.

@Lock

When using Container managed concurrency (ConcurrencyManagementType.CONTAINER) with Singleton EJBs, the @Lock annotation can help define whether or not you want allow concurrent access to your bean methods. If this annotation is not used, the default value is LockType.WRITE (enum) which signifies that the method cannot be accessed by multiple threads at the same time. The other option LockType.READ, behaves in exactly the opposite manner i.e. it allows multiple threads to concurrently access this method given that there is no thread which is currently holding a write lock on the Singleton bean instance.

Download full book

Just visit the book page and click the Add Ebook to Cart button . Don’t worry, as I mentioned earlier, it won’t cost you a penny!





About List