Question Quand utiliser l'annotation @Singleton de Jersey?


Je développe un service Web RESTful et en lisant le Jersey Documentation Je suis tombé sur une annotation @Singleton

Dans mon service Web, je retourne principalement des données basées sur les clés uniques fournies en paramètre. Une analogie serait de retourner toutes les informations d'un élève lorsque le Student_Id est passé.

Donc ma question est quand @Singleton serait adapté dans un tel type de services Web?

Selon la documentation pour @RequestScoped

Si la ressource est utilisée plusieurs fois dans le traitement de la demande, la même instance sera toujours utilisée.

Alors, dans ce cas, nous ne devrions pas prendre la peine d'utiliser @Singleton droite?

Aussi, quels pourraient être les cas d'utilisation où nous devons créer une nouvelle instance pour chaque requête?

J'ai regardé ce post mais ma question n'a pas été répondue.


23
2017-09-20 10:07


origine


Réponses:


Par défaut, Jersey crée une nouvelle instance de la classe de ressources pour chaque requête. Donc, si vous n’annotez pas la classe de ressources Jersey, elle utilise implicitement @RequestScoped portée. Il est indiqué dans Documentation de Jersey:

Cycle de vie par défaut (appliqué lorsqu'aucune annotation n'est présente). Dans ce   portée l'instance de ressource est créée pour chaque nouvelle demande et utilisée   pour le traitement de cette demande. Si la ressource est utilisée plus d'un   Dans le traitement de la demande, la même instance sera toujours utilisée.   Cela peut se produire lorsqu'une ressource est une sous-ressource renvoyée plus   fois pendant la correspondance. Dans cette situation, seulement par exemple   serveur les demandes.

Dans la plupart des cas, vous utilisez ce paramètre par défaut afin de ne pas utiliser @Singleton portée. Vous pouvez également créer une classe de ressources singleton Jersey en utilisant @Singleton annotation. Ensuite, vous devez enregistrer la classe singleton dans le MyApplication classe, par exemple,

@Path("/resource")
@Singleton
public class JerseySingletonClass {
    //methods ...
}

public class MyApplication extends ResourceConfig {

    /*Register JAX-RS application components.*/
    public MyApplication () {
        register(JerseySingletonClass.class);
    }
}

24
2017-12-10 21:43



Dans la plupart des cas, la portée par défaut @RequestScoped devrait être suffisant pour vos besoins.

@Singleton peut contenir l'état. J'ai eu le problème lorsque mon point final a été annoté comme @Singleton donc il a réutilisé le même EntityManager lors d'appels simultanés. Après avoir enlevé @Singleton, lors d'appels simultanés, différents EntityManager les instances d'objet sont utilisées. Si les appels de point final sont ultérieurs, il se peut que l'ancien / ancien EntityManager sera utilisé. - Jersey, Guice et Hibernate - Sécurité des threads EntityManager


0
2018-03-21 13:40



Il y a en fait un cas d'utilisation spécifié dans le manuel de Jersey 2 pour l'utilisation du SseBroadcaster lors de la diffusion d'événements Server-Sent, il est couvert dans cet exemple fourni 

La classe de ressources BroadcasterResource est annotée avec l'annotation @Singleton, qui indique à Jersey runtime que seule une instance de la classe de ressources doit être utilisée pour traiter toutes les demandes entrantes vers / le chemin de diffusion. Cela est nécessaire car nous voulons conserver une référence unique à l'échelle de l'application dans le champ du diffuseur privé afin que nous puissions utiliser la même instance pour toutes les demandes. Les clients qui souhaitent écouter les événements SSE envoient d'abord une requête GET à BroadcasterResource, qui est gérée par la méthode de ressource listenToBroadcast ().

En utilisant le @Singleton, L'application ne contiendra qu'un SseBroadcaster pour toutes les demandes entrantes, un tel diffuseur suffit à desservir plusieurs clients, il suffit donc de l'instancier une seule fois!

L'API SSE JAX-RS définit SseBroadcaster qui permet de diffuser des événements individuels à plusieurs clients.


0
2018-06-17 09:52