Singleton Overview

For the first time in years EJB has a new bean type, the @Singleton. In my opinion, the Singleton is going to replace a lot of what people are using @Stateless for today.

The Singleton is essentially what you get if you take a Stateless bean and adjust the pool size to be exactly 1 and optionally allow concurrent access to that bean like a servlet. It can do everything a Stateless can do such as support Web Services, Security, Transactions, etc. It will have an @Startup annotation which is similar in concept to the servlet <load-on-startup>, but unlike servlets it doesn't take a number as an argument. Instead, you can use an @DependsOn annotation to say which other Singletons you need and the container will ensure they start before you.

Concurrency

Singletons support two modes of concurrent access, Container-Managed Concurrency (the default) and Bean-Managed Concurrency.

Bean-Managed Concurrency

With Bean-Managed Concurrency, annotated as @ConcurrencyManagement(BEAN), the container sends all invocations into the bean and let's the Singleton bean instance decide how and when to synchronize access, if at all. Here the 'synchronization' keyword is allowed as well as the full javax.util.concurrent set of libraries.

Container-Managed Concurrency

With Container-Managed Concurrency, annotated as @ConcurrencyManagement(CONTAINER), the container will enforce concurrency for you via locking method access to the bean. Two modes, called locks will exist and can be assigned to the class or on a per method basis.

Write Lock

The first and the default is a "write" lock, annotated as @Lock(WRITE). Essentially with a write lock, the caller hold an exclusive lock on the bean for the duration of the method call and all other threads for that or any other method must wait.

Read Lock

The second option is a "read" lock, annotated as @Lock(READ). The read lock allows full concurrent access to the methods (assuming no write locks are held). The default mode of "write" will essentially make your bean a single-threaded bean, which is very slow. The more conservative @Lock(WRITE) as chosen as the default as this is how all the other bean types work (on a single thread may access a bean instance at any given time). Those that are aware of how to handle concurrent access can easily put @Lock(READ) on their bean class, thus changing the default, and then @Lock(WRITE) on specific methods if needed.

Relation to java.util.concurrent.ReadWriteLock

The locking modes of Container-Managed Concurrency map directly to the java.util.concurrent.ReadWriteLock API which looks like this:

public interface ReadWriteLock {
   /**
    * Returns the lock used for reading.
    *
    * @return the lock used for reading.
    */
   Lock readLock();

   /**
    * Returns the lock used for writing.
    *
    * @return the lock used for writing.
    */
   Lock writeLock();
}

Literally 100% of the singleton locking we're talking about is taken from this interface. It's safe to imagine that under the covers the Singleton Container is creating an instance of ReadWriteLock which it will use to enforce the locking for all the Singleton bean's methods. Essentially:

• @Lock(READ) == theSingletonReadWriteLock.readLock().lock()
• @Lock(WRITE) == theSingletonReadWriteLock.writeLock().lock()

Example Code