Partner – Payara – NPI (cat=Jakarta EE)
announcement - icon

Can Jakarta EE be used to develop microservices? The answer is a resounding ‘yes’!

>> Demystifying Microservices for Jakarta EE & Java EE Developers

Course – LS – All

Get started with Spring and Spring Boot, through the Learn Spring course:

>> CHECK OUT THE COURSE

1. Overview

In this tutorial, we’ll take a closer look at two types of singletons available in Jakarta EE. We’ll explain and demonstrate the differences and see the usages suitable for each one.

First, let’s see what singletons are all about before getting into the details.

2. Singleton Design Pattern

Recall that a common way to implement Singleton Pattern is with a static instance and private constructor:

public final class Singleton {
    private static final Singleton instance = new Singleton();

    private Singleton() {}

    public static Singleton getInstance() {
        return instance;
    }
}

But, alas, this isn’t really object-oriented. And it has some multi-threading issues.

CDI and EJB containers give us an object-oriented alternative, though.

3. CDI Singleton

With CDI (Contexts and Dependency Injection), we can easily create singletons using the @Singleton annotation. This annotation is a part of the javax.inject package. It instructs the container to instantiate the singleton once and passes its reference to other objects during the injection.

As we can see, singleton implementation with CDI is very simple:

@Singleton
public class CarServiceSingleton {
    // ...
}

Our class simulates a car service shop. We have a lot of instances of various Cars, but they all use the same shop for servicing. Therefore, Singleton is a good fit.

We can verify it is the same instance with a simple JUnit test that asks the context for the class twice. Note that we’ve got a getBean helper method here for readability:

@Test
public void givenASingleton_whenGetBeanIsCalledTwice_thenTheSameInstanceIsReturned() {       
    CarServiceSingleton one = getBean(CarServiceSingleton.class);
    CarServiceSingleton two = getBean(CarServiceSingleton.class);
    assertTrue(one == two);
}

Because of the @Singleton annotation, the container will return the same reference both times. If we try this with a plain managed bean, however, the container will provide a different instance each time.

And while this works the same for either javax.inject.Singleton or javax.ejb.Singleton, there’s a key difference between these two.

4. EJB Singleton

To create an EJB singleton we use the @Singleton annotation from the javax.ejb package. This way we create a Singleton Session Bean.

We can test this implementation the same way we tested the CDI implementation in the previous example, and the result will be the same. EJB singletons, as expected, provide the single instance of the class.

However, EJB Singletons also provide additional functionality in the form of container-managed concurrency control.

When we use this type of implementation, the EJB container ensures that every public method of the class is accessed by a single thread at a time. If multiple threads try to access the same method, only one thread gets to use it while others wait for their turn.

We can verify this behavior with a simple test. We’ll introduce a service queue simulation for our singleton classes:

private static int serviceQueue;

public int service(Car car) {
    serviceQueue++;
    Thread.sleep(100);
    car.setServiced(true); 
    serviceQueue--;
    return serviceQueue;
}

serviceQueue is implemented as a plain static integer which increases when a car “enters” the service and decreased when it “leaves”. If proper locking is provided by the container, this variable should be equal to zero before and after the service, and equal to one during the service.

We can check that behavior with a simple test:

@Test
public void whenEjb_thenLockingIsProvided() {
    for (int i = 0; i < 10; i++) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                int serviceQueue = carServiceEjbSingleton.service(new Car("Speedster xyz"));
                assertEquals(0, serviceQueue);
            }
        }).start();
    }
    return;
}

This test starts 10 parallel threads. Each thread instantiates a car and tries to service it. After the service, it asserts that the value of the serviceQueue is back to zero.

If we, for instance, execute a similar test on the CDI singleton, our test will fail.

5. Conclusion

In this article, we went through two types of singleton implementations available in Jakarta EE. We saw their advantages and disadvantages and we also demonstrated how and when to use each one.

And, as always, the complete source code is available over on GitHub.

Course – LS – All

Get started with Spring and Spring Boot, through the Learn Spring course:

>> CHECK OUT THE COURSE
res – REST with Spring (eBook) (everywhere)
Comments are closed on this article!