When to use @Singleton annotation of Jersey?

Question

I am developing a RESTful Web Service and while reading the Jersey documentation I came across an annotation @Singleton

In my web service I am mostly returning data based on the unique keys provided as parameter. An analogy would be return all the information of a Student when the Student_Id is passed.

So my question is when @Singleton would be suited in such kind of Web Services?

As per documentation for @RequestScoped

If the resource is used more than one time in the request processing, always the same instance will be used.

Then in that case we should not bother to use @Singleton right?

Also what could be the use cases where we have to make a new instance for every request?

I did have a look at this post but my question was not answered.

Answer 1

By default Jersey creates a new instance of the resource class for every request. So if you don't annotate the Jersey resource class, it implicitly uses @RequestScoped scope. It is stated in Jersey documentation:

Default lifecycle (applied when no annotation is present). In this scope the resource instance is created for each new request and used for processing of this request. If the resource is used more than one time in the request processing, always the same instance will be used. This can happen when a resource is a sub resource is returned more times during the matching. In this situation only on instance will server the requests.

Most cases you use this default setting so you don't use @Singleton scope. You can also create a singleton Jersey resource class by using @Singleton annotation. Then you need to register the singleton class in the MyApplication class, e.g.,

@Path("/resource") @Singleton public class JerseySingletonClass {     //methods ... }  public class MyApplication extends ResourceConfig {      /*Register JAX-RS application components.*/     public MyApplication () {         register(JerseySingletonClass.class);     } } 

Answer 2

Came along this question, because for the first time I had a use case for not using @Singleton annotation.

Singleton is a design pattern, you should use it if:

• The object you are "singletonizing" keeps a state that must be shared and kept unique (example: a global counter)
• Generally, I design REST API without keeping a state, everything is handled in the method (full closure): so generally all my resources are singletons (use case: better performance)

That said, today I found this use case for not using Singleton:

@Path("/someendpoint/{pathparam}/somethingelse/") //@Singleton public class MyResource {     @PathParam("pathparam")     private String pathparam; } 

Using this, I'm bounding the path param to my instance, so it must be RequestScoped. Generally, I'd have put @PathParam annotation in every method, so @Singleton would have been right on the class.

I'm not sure about the performances however, creating and destroying an object isn't a free operation