Home Blog About

Java EE Singleton Bean vs Singleton Pattern

 
DEEPAK KARANTH /

All developers know what a Singleton pattern is – It is a pattern that ensures that only one instance of an object is instantiated across the system.

Java EE also has a concept of Singleton – The Singleton Session Bean. Just use the javax.ejb.Singleton annotation on the bean class and it is treated as a singleton bean by the container. Indeed, the code looks great and easy to implement.

The Java EE documentation says “The EJB container is responsible for determining when to initialize a singleton session bean instance unless the singleton session bean implementation class is annotated with the javax.ejb.Startup annotation.”

A commonly quoted example from the Java EE documentation below.

@Singleton
public class SingletonSessionBean {
    
    private String status;
    
    @PostConstruct
    void init() {
        status = "Ready";
    }
}

Have a look at the below example. It is almost the same as the previous code, with the additional constructor added.

@Singleton
public class SingletonSessionBean {
    
    private String status;

    public SingletonSessionBean() {
        System.out.println("In SingletonSessionBean constructor");
    }
    
    @PostConstruct
    void init() {
        status = "Ready";
    }
}

We expect both the beans to behave in the exact same manner, isn’t it? Well, to say the least, the behind the scenes behavior is not as you would expect it to be.

Lets look into it in more detail.

We expect that only one instance of the bean is created in the EJB container and all requests are handled by that one instance.

Upon executing the code in WildFly, we found that the default constructor was called many times. However, the method annotated with post constructor is executed only once.

So, it appears that apart from the constructor being invoked many times, rest of the code in the Singleton bean behaves as expected. This is a really confusing behavior for most people because their minds associate the Singleton bean with the well-known Singleton pattern.

Upon further investigation, we found the following in the Java EE specification.


The developer of an enterprise bean that exposes a no-interface view must not make any assumptions about the number of times the bean class no-arg constructor will be called.For example, it is possible that the acquisition of a client reference to the no-interface view will result in the invocation of the bean class constructor. It is recommended that the Bean Provider place component initialization logic in a PostConstruct method instead of the bean class no-arg constructor.

So, why is it named Singleton bean then? Well, from the client’s perspective it still behaves as singleton.

All references to the no-interface view of the same stateless session bean have the same object identity. What it means is that beanRef1.equals(beanRef2) for the same no-interface view Singleton Bean would return true.

So, keep in mind not to have a default no-arg constructor when developing a no-interface view Singleton Session bean.

PS: Are you wondering why an image of Statue of Liberty image has been used in this post? Things are never what they appear to be, there is not one but many statues of liberty. Have a look at the following Wikipedia article – Replicas of the Statue of Liberty


 
comments powered by Disqus