Stateless Session Beans gegen Singleton Session Beans
Den Java EE 6 Tutorial sagt:
Um die Leistung zu verbessern, könnten Sie ein stateless session bean, wenn es eines dieser Merkmale:
- Den bean-Zustand-hat keine Daten für einen bestimmten client.
- In einem einzigen Methodenaufruf, der Bohne führt eine generische Aufgabe für alle Kunden. Zum Beispiel, können Sie eine zustandslose session-bean eine E-Mail senden, die bestätigt eine online-Bestellung.
- Der bean implementiert einen web service.
Singleton session beans sind in den entsprechenden folgenden Umständen:
- Staat muss geteilt werden, die in der gesamten Anwendung.
- Einer einzigen enterprise-bean zugegriffen werden muss von mehreren threads gleichzeitig genutzt werden.
- Muss die Anwendung eine enterprise-bean, um Aufgaben, die auf Anwendung starten und Herunterfahren.
- Der bean implementiert einen web service.
Aber was zu verwenden, wenn:
- kein Staat muss geteilt werden, die über die Anwendung
- einer einzigen enterprise-bean zugegriffen werden konnte, die von mehreren threads gleichzeitig
- keine tasks auf Systemstart oder shotdown durchgeführt werden müssen
Sagen, ich habe zum Beispiel ein login-service mit folgender Schnittstelle:
public interface LoginService {
boolean authenticate(String user, String password);
}Sollte es werden annotiert mit @Singleton oder @Stateless? Was sind die Vorteile des einen und des anderen? Was ist, wenn LoginService muss man injiziert ein EntityManager (das wäre gleichzeitig verwendet werden)?
Zusatz: ich denke über die Java EE-Pendant des Frühlings-service-Bohnen, die zustandslos sind singletons. Wenn ich verstehe richtig, dass die Java EE-Pendant sind die @Stateless-session-beans und @Singleton-Beans werden verwendet, um zu konfigurieren Sie die Anwendung beim Start oder Aufräumarbeiten beim beenden oder zu halten Sie Anwendung große Objekte. Ist das richtig?
InformationsquelleAutor der Frage deamon | 2010-01-06
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich würde für Stateless - server generieren kann viele Instanzen der bean und verarbeiten eingehende Anfragen parallel.
Singleton klingt wie ein potenzieller Engpass - Standard @Lock Wert ist @Lock(WRITE), kann aber geändert werden, um @Lock(READ) für die bean oder einzelne Methoden.
InformationsquelleAutor der Antwort mjn
gemäß der ejb-3.1-Spezifikation, Seite 110, Kapitel 4.8.5 "Singleton-Concurrency":
und darüber hinaus nach den hibernate entitymanager-Dokumentation
Für mich bedeutet dies, dass Sie niemals injizieren einen EntityManager in ein singleton EJB. Ich würde die Verwendung einer singleton-EJB, die als Ersatz für eine stateless EJB nur, wenn ALLES, was ich implementieren müssen, um in diese Klasse unterstützt die Parallelität, ohne die Notwendigkeit zu tun, eine zusätzliche Sicherung /Synchronisierung. Wie Sie oder andere Programmierer verlieren könnte dieses Problem früher oder später von Ihrem Fokus, ich persönlich bevorzuge nicht zu verwenden singleton-EJBs, außer für die Start-bezogene Probleme oder features, die implementiert werden können als in sich geschlossene Einheiten - unabhängig von den anderen Bohnen. In diesem Sinne, es scheint nicht ratsam zu injizieren, zum Beispiel Stateless EJBs in Singletons. Dabei stellt sich die Frage nach dem Zeitpunkt, wenn der Behälter tatsächlich führt die Injektion des SLSB in den Singleton? Nach der EJB-3.1-Spezifikation, Kapitel 4.8, die dependency injection gemacht wird, bevor die singleton-bean-Instanz zugegriffen werden kann Kunden. Also die singleton-natürlich-stick auf die gleiche Instanz des SLSB, das scheint sich zu einem singleton-implizit, aber es scheint nicht zu sein, keine Gewähr für, die. Zumindest konnte ich nicht finden, alles, was in den specs, also das Verhalten kann unberechenbar sein oder im besten Fall ein container-spezifisches, das ist nicht das, was die meisten Menschen wollen.
So, ich würde nur zu injizieren Singleton in Singleton oder Singletons in SLSBs aber nicht Umgekehrt. Für den Fall einer Injektion von einem Singleton in Singleton, die Skillung bietet Ihnen die Möglichkeit zu definieren, die Abhängigkeiten zwischen den singletons, so dass die container initialisieren kann diese in der richtigen Reihenfolge (siehe ejb-3.1-Spezifikation, Kapitel 4.8.1 über die @DependsOn annotation).
InformationsquelleAutor der Antwort stephan_bauer
@Statelessermöglicht es Ihnen, mehrere Kopien bereit für die Bearbeitung innerhalb einer JVM (so viel wie die Speicher-und pool-Größe erlaubt), wo-als @Singleton ist es nur eine Kopie in einer JVM, auch wenn die einzelne einen unterstützen können mehrere threads gleichzeitig ausgeführt werden.In Bezug auf Leistung
@Singletonbesser wäre, vorausgesetzt, dass die Ressourcen, die Sie verwendet lange mit access. Jedoch, in einer verteilten Umgebung manchmal schlechte Dinge passieren, wie z.B. eine Datenbank oder Netzwerk-verbindungen fehlschlagen.Mit einem
@Statelessbean, das Zugang nur von kurzer Dauer. Darüber hinaus sollte es einen Ausfall wird es nur respawn und versuchen eine neue Verbindung aufzubauen, um die Ressource. Wenn etwas passiert, wie das auf ein singleton ist, dann ist es das singleton zu behandeln, ohne dass ein Neustart der Applikation, weil die @PostConstruct wird nur aufgerufen, einmal pro JVM.Ich würde es vorziehen, ein wenig Fehlertoleranz vs Leistung für die meisten Situationen, vor allem auf Systeme, die ich keine Kontrolle habe.
InformationsquelleAutor der Antwort Archimedes Trajano
Ich denke, dass Singleton in Parallelität Nutzung nicht schlechter als SLSB Pool, es könnte noch besser sein. Das problem ist nur, wenn Sie teilen wollen etwas zwischen threads, die Sie benötigen, zu sperren, und das könnte ein großes problem sein bei der Leistung. So in diesem Fall, eine SLSB Pool deutlich besser, weil es nicht 100% singleton, gibt es mehrere Instanzen, wurde man gesperrt, der andere kommt. Jedenfalls, wenn die Sperre auf einer Ressource gemeinsame Nutzung durch alle SLSBs, der pool wird nicht helfen, weder.
Kurzum, ich denke, singleton ist besser als SLSB-Pool, die Sie verwenden sollten, wenn Sie können. Es ist auch der default-scope für Spring Beans.
Bin ich nicht ein Java ee-Experte, das ist nur mein Gefühl, bitte korrigieren Sie mich, wenn ich falsch Liege.
InformationsquelleAutor der Antwort cn1h
Ich glaube, Sie sollten Singleton session bean. Da ein login service ist ein globaler Dienst, und er muss nicht zum speichern jeder Staat für einen konkreten Benutzer oder Anrufung.
InformationsquelleAutor der Antwort Yang Lifan
Wenn Sie sicher sind Sie nicht die Freigabe des Zustands zwischen threads, dann ein Singleton wird in Ordnung sein, in dem Fall sollten Sie auch mit Anmerkungen versehen Sie die Klasse mit
@ConcurrencyManagement( ConcurrencyManagementType.BEAN )die es erlauben, mehrere threads gleichzeitig ausgeführt werden.InformationsquelleAutor der Antwort Rothron
sollten Sie gehen für das Singleton, wenn Sie jede Ressource, die wird konstant bleiben, die in der gesamten Anwendung. Wie laden einige der Daten aus einer Datei oder Referenz-Daten, die nicht ändern würde, über den application lifecycle. andernfalls gehen Sie für SLSB. Der Nachteil von SLSB ist, dass mehrere Objekte erstellt werden, damit mehr Speicher wäre besetzt.
InformationsquelleAutor der Antwort Hammad Dar
Imho würde ich Antworten wie:
"kein Staat muss geteilt werden, die über die Anwendung" führt mich zu stateless-bean, denn der Satz "um die Leistung Zu verbessern, könnten Sie ein stateless session bean...".
Angesichts "einer einzigen enterprise-bean zugegriffen werden konnte, die von mehreren threads gleichzeitig" würden Sie verwenden singleton. Wenn ich es richtig es ist nicht einmal möglich, den Zugriff auf eine stateless bean ist gleichzeitig, wenn Sie richtig verwendet werden.
"keine tasks auf Systemstart oder shotdown durchgeführt werden müssen" würde, ist mir das egal. Wenn Aufgaben durchgeführt werden müssen, um richtig setup eine Bohne dann haben Sie geltend gemacht werden, @PostActivate Methode.
Ich würde logisch schlussfolgern, Ihre Frage, was zu verwenden, um die @Singleton seit Ihr gefragt für gleichzeitigen Zugriff. Natürlich müssen Sie manuell Steuern snychronisation der Zugriff auf alle weiteren Ressourcen (die nicht EJBs).
InformationsquelleAutor der Antwort Dirk Schumacher