Singleton Session EJB
Internal
Concepts
Overview
A singleton session bean is a component that is instantiated once per application. For distributed applications that span multiple VMs, each application will have on singleton session bean instance per JVM. The instances are intended to be shard, and must support concurrent access. The Singleton bean instances maintain state between invocations, but the state is not required to survive container shutdown or crash.
Lifecycle
Instantiation
The singletons are lazy instantiated by default. The container instantiates them when the first invocation arrives. However, a Singleton bean can declare that it needs eager initialization, when the application starts, by declaring the @Startup annotation. If eagerly initialized, it is the container's responsibility to initialize the bean before any external client requests are delivered to the instance.
To create the instance, the container invokes newInstance() method on the Singleton bean class. Then the container performs any dependency injection. Then the container calls @PostConstruct methods.
If a failure occurs during the Singleton initialization, it is considered fatal and the instance is discarded.
@PostConstruct methods for Singletons with container-managed transaction are transactional. See EJB 3.1 Specification Section 4.8.3.
Dependencies
A Singleton bean may declare an initialization dependency on another Singleton bean instance, by declaring the @DependsOn annotations. More details on dependencies available in @DependsOn.
Active Life
Once instantiated according to the previous sequence, the Singleton bean instance lives for the duration of the application. Unlike instances of other component types, system exceptions thrown from business methods or callbacks of a Singleton do not result in the destruction of the instance.
Destruction
When the application is shutting down, the container invokes @PreDestroy methods, and this ends the life of the instance.
Note that during destruction, the container ensures that all Singleton beans on which this instance @DependsOn are still available during the instance's @PreDestroy methods.
@PreDestroy methods for Singletons with container-managed transaction are transactional. See EJB 3.1 Specification Section 4.8.3.
Concurrency
Singleton beans are interned to support concurrent access. The developer may choose between bean-managed concurrency, where the container allows full concurrent access and state access synchronization is the responsibility of the developer, and container-managed concurrency, where the container manages concurrent access, according to method-level locking metadata. A Singleton bean can be designed to use either method, but not both. The default behavior when nothing is explicitly specified, is container-managed concurrency.
Also see
Interceptors
Restrictions
Singleton beans must not implement javax.ejb.SessionSychronization interface or use the session synchronization annotations.