@Singleton vs @ApplicationScope

Für ein Projekt benötige ich eine eindeutige ID generator. So dachte ich über ein Singleton mit synchronisierten Methoden.

Da ein Singleton nach der traditionellen Singleton-Muster (private static instance) gemeinsam auf Sitzungen, Frage ich mich, ob die @Singleton Annotation ist die Arbeit die gleiche Weise?

In der Dokumentation sagt: Identifies a type that the injector only instantiates once.

Bedeutet es, dass ein @Singleton unabhängig pro User Session (was schlecht ist für ein id-generator)? Sollte ich lieber eine old school Singleton mit Class.getInstance() über eine Injektion einer @Singleton-Bean?

Oder sollte ich weder noch und bieten den Service, innerhalb einer @ApplicationScoped bean?

es musst garantiert werden, dass nur EIN thread, unabhängig von der Benutzer-session zugreifen können, die Methode zum generieren der nächsten id. (Es ist nicht lösbar mit auto-Inkrement-Datenbank-ids)

Edit: JSF 2.2, CDI und javax.inject.* ich Rede 🙂

InformationsquelleAutor dognose | 2014-11-09
  1. 21

    Alle diese Arten von singletons (static, @javax.inject.Singleton, @javax.ejb.Singleton und @javax.enterprise.context.ApplicationScoped) erstellt werden einmal pro JVM.

    Einem Objekt, das erstellt wird, einmal pro Benutzer-Sitzung muss kommentiert werden mit @javax.enterprise.context.SessionScoped so nicht, singletons wird nicht instanziiert werden pro Benutzer-session.

    Beachten Sie, dass es zwei @Singleton Anmerkungen, eine in javax.inject und die andere in der javax.ebj Paket. Ich beziehe mich auf die Ihnen von Ihren voll qualifizierten Namen, um Verwechslungen zu vermeiden.

    Die Unterschiede zwischen all denen, die singletons sind nur Nuancen und ich bin mir nicht sicher, ich kenne alle Folgen, aber ein paar in den Sinn kommen:

    • @javax.ejb.Singleton verwaltet der EJB-container und so kann es Transaktionen (@javax.ejb.TransactionAttribute), Lesen/schreiben sperren und time-outs (@javax.ejb.Lock, @javax.ejb.AccessTimeout), Start der Anwendung (@javax.ejb.Startup, @javax.ejb.DependsOn) und so weiter.
    • @javax.enterprise.context.ApplicationScoped verwaltet der CDI-container, so dass Sie nicht haben, die Transaktions-und locking-Funktionen, die EJB hat (es sei denn, Sie verwenden einen post-CDI 1.0, die Hinzugefügt hat, Transaktionen), aber Sie haben noch viele nette Dinge wie @javax.enterprise.inject.Produces, @javax.annotation.PostConstruct, @javax.inject.Named, @javax.enterprise.inject.Disposes (viele dieser features sind verfügbar, um EJBs zu).
    • @javax.inject.Singleton ist ähnlich @ApplicationScoped, außer dass es keine proxy-Objekt (Kunden haben einen Verweis direkt auf das Objekt). Es wird weniger Umweg zu erreichen, das Reale Objekt, aber dies könnte Ursache einige Fragen im Zusammenhang mit der Serialisierung (siehe: http://docs.jboss.org/weld/reference/latest-2.2/en-US/html_single/#_the_singleton_pseudo_scope)
    • Einem einfachen statischen Feld ist einfach und funktioniert, aber es ist gesteuert durch den class-loader so zu verstehen, wie/wenn Sie instanziiert sind und Müll gesammelt (wenn überhaupt), werden Sie brauchen, um zu verstehen, wie Klassen-Lader arbeiten und wie Sie Ihre Applikation-server verwaltet seine Klasse Lader. Sehen diese Frage für mehr details.
    InformationsquelleAutor marcus
  2. 0

    javax.injizieren.Singleton - Wenn Ihr Bohnen, Sie haben zu implementieren writeResolve() und readReplace zu vermeiden Serialisierung Probleme. Verwenden Sie es mit bedacht, basierend auf, was Ihre bean eigentlich in ihm hat.

    javax.enterprise.Kontext.ApplicationScoped - Ermöglicht den container, um die proxy-bean und kümmern sich um die Serialisierung automatisch. Dies wird empfohlen, um zu vermeiden, noch nie dagewesene Probleme.

    Weitere Informationen finden Sie diese Seite Nummer 45.

    InformationsquelleAutor srk
Schreibe einen Kommentar