Singleton Session EJB

Internal

• EJB

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. Regardless of the concurrency management method, the container will insure that there is no concurrent access until after @PostConstruct methods successfully complete.

It is legal to store JEE objects that do not support concurrent access within Singleton bean instances, but it the responsibility of the developer to ensure such objects are not accessed by more than one thread at a time.

Singleton beans support reentrant calls (EJB 3.1 Spec Section 4.8.5.1.1).

If the developer chooses to use container-managed concurrency, the container controls concurrent access based on method-level locking metadata. Each business method may be associated with either a shared @Read lock or an exclusive @Write lock. If not annotation is specified, the method defaults to a @Write lock.

If the method is annotated with @Read, the container allows any number of concurrent invocations. If the method is annotated with @Write, no other concurrent invocation will be allowed until the initial thread successfully completes method execution. More details on concurrency metadata, including the rules that apply in case of inheritance are described in EJB 3.1 specifications, sections 4.8.5.4, and 4.8.5.5.

If the lock is not acquired within a certain amount of time, timeouts can be specified via metadata. If an invocation fails due to lock timeout, the container will throw ConcurrentAccessTimeoutException.

Also see

EJB Concepts - Concurrency

Interceptors

The interceptor classes associated with a Singleton bean have the same lifecycle and concurrency behavior as that Singleton. Each interceptor class will be instantiated once per Singleton bean instance.

Restrictions

Singleton beans must not implement javax.ejb.SessionSychronization interface or use the session synchronization annotations.