Cuándo usar la anotación @Singleton de Jersey?

Estoy desarrollando un servicio web RESTful y mientras leía la documentación de Jersey encontré una anotación @Singleton

En mi servicio web estoy principalmente devolviendo datos basados ​​en las claves únicas proporcionadas como parámetro. Una analogía sería devolver toda la información de un Estudiante cuando se pasa el ID de Estudiante.

Entonces, mi pregunta es cuándo @Singleton sería adecuado para ese tipo de servicios web.

Según la documentación de @RequestScoped

Si el recurso se usa más de una vez en el proceso de solicitud, siempre se usará la misma instancia.

Entonces, en ese caso, no deberíamos molestarnos en usar @Singleton ¿verdad?

Además, ¿cuáles podrían ser los casos de uso en los que tenemos que crear una nueva instancia para cada solicitud?

Eché un vistazo a esta publicación pero mi pregunta no fue respondida.

De forma predeterminada, Jersey crea una nueva instancia de la clase de recurso para cada solicitud. Entonces, si no anota la clase de recursos de Jersey, implícitamente usa el scope de @RequestScoped . Está indicado en la documentación de Jersey :

Ciclo de vida predeterminado (se aplica cuando no hay anotaciones). En este ámbito, la instancia de recurso se crea para cada nueva solicitud y se utiliza para procesar esta solicitud. Si el recurso se usa más de una vez en el proceso de solicitud, siempre se usará la misma instancia. Esto puede suceder cuando un recurso es un recurso secundario que se devuelve más veces durante la coincidencia. En esta situación, solo en instancia atenderá las solicitudes.

La mayoría de los casos usa esta configuración predeterminada para que no use el scope de @Singleton . También puede crear una clase de recursos Jersey singleton utilizando la anotación @Singleton . Luego necesita registrar la clase singleton en la clase MyApplication , por ejemplo,

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

En la mayoría de los casos, el scope predeterminado @RequestScoped debería ser suficiente para sus necesidades.

@Singleton puede mantener el estado. Tuve el problema cuando mi punto final se anotó como @Singleton por lo que reutilizó el mismo EntityManager durante las llamadas simultáneas. Después de eliminar @Singleton , durante las llamadas concurrentes, se EntityManager diferentes instancias de objeto EntityManager . Si las llamadas a punto final son posteriores, es posible que se EntityManager anterior / anterior. – Jersey, Guice e Hibernate – Seguridad de hilo de EntityManager

En realidad, hay un caso de uso especificado en el manual de Jersey 2 para usar el SseBroadcaster cuando se atienden eventos enviados por el servidor, este está cubierto en este ejemplo.

La clase de recurso BroadcasterResource se anota con la anotación @Singleton que le dice al tiempo de ejecución de Jersey que solo una instancia única de la clase de recurso se debe usar para atender todas las solicitudes entrantes a / vía de transmisión. Esto es necesario ya que queremos mantener una sola referencia en toda la aplicación para el campo de la emisora ​​privada para que podamos usar la misma instancia para todas las solicitudes. Los clientes que desean escuchar eventos SSE primero envían una solicitud GET a BroadcasterResource, que se maneja con el método de recurso listenToBroadcast ().

Usando el @Singleton , la aplicación solo contendrá un SseBroadcaster para todas las solicitudes entrantes, una de ellas es suficiente para servir a múltiples clientes, ¡así que solo necesita una instancia una vez!

JAX-RS SSE API define SseBroadcaster, que permite transmitir eventos individuales a múltiples clientes.