JavaEE & JAX-RS: Resource Class Should Be Declared as Singleton or Stateless?

Question

Looking at listing #1 at the following tutorial,

JAX-RS resource classes can be defined as @Stateless or @Singleton.

I have the following code in my application:

@Stateless
public class VisitDaoImpl implements VisitDao {

    @PersistenceContext(name = "MysqlPU")
    private EntityManager em;

    @Override
    public void persist(Visit vist) {
        em.persist(vist);
    }
}

@ApplicationPath("rest")
public class ApplicationConfig extends Application {

    @Override
    public Set<Class<?>> getClasses() {
        Set<Class<?>> resources = new java.util.HashSet<>();
        resources.add(WelcomeResource.class);
        return resources;
    }
}

//@Singleton
@Stateless
@Path("/Welcome")
public class WelcomeResource {

    @EJB
    private VisitDao visitDao;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String wellcomeMessage() {
        visitDao.persist(new Visit())
        return "Welcome";
    }
}

As you can see I do not have state in my resource class except for the Dao bean.

My questions are:

1. Should I use @Stateless or @Singleton bean here?
2. When to favor one of them on the other in JAX-RS resource classes?

Thank you.

Answer 1

I think @Stateless if you want to perform write operations to the database or other methods affecting state.

Multiple threads (clients) would have to wait for the singleton to come available as default Lock is write in singleton-ejbs.

from java-ee-6 tutorial:

Annotating a singleton class with @Lock specifies that all the business methods and any timeout methods of the singleton will use the specified lock type unless they explicitly set the lock type with a method-level @Lock annotation. If no @Lock annotation is present on the singleton class, the default lock type, @Lock(WRITE), is applied to all business and timeout methods.

In the example, there is an ejb-dao in between your @Path-ejb and the database. Which suggests you might be able to change to @Singleton and use @Lock(READ) on your bussiness method (no idea why anyone would wanna try).

But I don't think that is safe, as the same ejb-dao-instance would be used for all concurrent invocations done by the clients and the EntityManager the DAO is holding is not thread-safe:

from java-ee-6 tutorial:

Application-managed entity managers are used when applications need to access a persistence context that is not propagated with the JTA transaction across EntityManager instances in a particular persistence unit. In this case, each EntityManager creates a new, isolated persistence context. The EntityManager and its associated persistence context are created and destroyed explicitly by the application. They are also used when directly injecting EntityManager instances can’t be done because EntityManager instances are not thread-safe. EntityManagerFactory instances are thread-safe.

Answer 2

Recommended approach for stateless objects to be Singleton in Spring, look this question and Spring current guide. Thus, according to spring, you should use Singleton since your Rest Service is stateless.

5.5.2 The prototype scope

The non-singleton, prototype scope of bean deployment results in the creation of a new bean instance every time a request for that specific bean is made. That is, the bean is injected into another bean or you request it through a getBean() method call on the container. As a rule, use the prototype scope for all stateful beans and the singleton scope for stateless beans.

But according to Enterprise Beans Java Tutorial, you can use either stateless bean or singleton, since they explicitly state that "The bean implements a web service." for both stateless and singleton. But stateless bean may be better choice due to singleton pitfalls. In the end, use singleton in Spring, stateless bean in JavaEE.

Answer 3

First off: in your case I think the answer should be "neither". There is no reason for your JAX-RS class to also be an EJB. You can still inject EJBs into it (JAX-RS supports this), so do all your EJB-ey stuff (like database transactions) in injected EJBs (like your VisitDao) and keep your REST classes small and simple - remember: single responsibility principle.

@Stateless or @Singleton

I see that people tend to use @Stateless. Like explained in other answers, this results in a pool of EJBs as EJB by default assumes your classes are not thread-safe so it will never allow multiple threads into a single instance at once. The size of the pool is controlled by your app server config. If more threads want to access the session bean than there are available instances in the pool (and the pool max size does not allow more to be created), the thread needs to wait.

Because of this risk of thread contention when running in high-traffic situations, plus the fact that if you program your session beans properly, they actually will be thread-safe, I've started to move to a pattern where I annotate my EJBs as @Startup @Singleton ConcurrencyManagement(ConcurrencyManagementType.BEAN). This means:

1. only a single instance of the bean will ever be created (so you don't waste memory on multiple instances)
2. it will be created as soon as your application starts up (so no more expensive and time-consuming resource allocation once your app is running and requests start coming in)
3. your bean is responsible for managing concurrency, i.e. for being thread-safe (just make sure you don't change any of your bean's fields after construction and initialization and you should be fine -- this is good practice anyway)

Incidentally, this is the default in Spring for beans and I think it is a good one (I have a Spring background so I might not be completely unbiased about this).