Warum Stateless Session-Beans Single-Threaded sind?

Question

Nach meinem Verständnis werden statusfreie Session-Beans verwendet, um die Geschäftslogik zu codieren. Sie können keine Daten in ihren Instanzvariablen speichern, da ihre Instanz von mehreren Anfragen gemeinsam genutzt wird. Sie scheinen eher Singleton-Klassen zu sein. Der Unterschied besteht jedoch darin, dass die separate Instanz von Stateless Session-Beans für jede Anforderung erstellt (oder aus dem Pool wiederverwendet) wird.

Nach dem googeln konnte ich die Argumentation finden, dass die Java EE-Spezifikation sagt, dass sie Singlethread sein sollen. Aber ich kann nicht den Grund bekommen, warum die EINZIGGEWINDE sind?

Answer 1

Die SLSBs sind aufgrund des TX-Kontextes single-threaded, Principal ist einer Bean-Instanz zugeordnet, wenn sie aufgerufen wird. Diese Beans werden gepoolt, und wenn die maximale Poolgröße nicht erreicht wird, werden sie in separaten Threads verarbeitet (herstellerabhängig).

Wenn SLSBs Thread-sicher entworfen wurden, hätte jeder Aufruf wie ein Servlet doGet/Post mit Anforderungsinformationen, die Tx Context, Sicherheitskontextinformationen usw. enthalten. So sieht der Code zumindest sauber aus (Entwickler abhängig).

Answer 2

Der Hauptgrund, dass statusfreie Session-Beans Single-Threading sind, besteht darin, sie für den Container hoch skalierbar zu machen. Der Container kann viele vereinfachende Annahmen über die Laufzeitumgebung treffen. Ein zweiter Grund besteht darin, dem Entwickler das Leben zu erleichtern, da sich der Entwickler keine Gedanken über Synchronisation oder Neueinführungen in seiner Geschäftslogik machen muss, da die Bean niemals in einem anderen Thread-Kontext aufgerufen wird.

Ich erinnere mich an die Begründung in den Bewertungen der ursprünglichen EJB 1.0-Spezifikation diskutiert. Ich würde auf den Zielbereich der Spezifikation schauen. Eine Liste der Spezifikationen finden Sie unter http://java.sun.com/products/ejb/docs.html.