Warum sind zustandslose Session-Beans Single-Threaded?

Question

Nach meinem Verständnis werden zustandslose Session-Beans zum Codieren der Geschäftslogik verwendet.Sie können keine Daten in ihren Instanzvariablen speichern, da ihre Instanz von mehreren Anforderungen gemeinsam genutzt wird.Sie scheinen also eher Singleton-Klassen zu sein.Der Unterschied besteht jedoch darin, dass „Content“ für jede Anforderung eine separate Instanz zustandsloser Session-Beans erstellt (oder aus dem Pool wiederverwendet).

Nach dem Googeln konnte ich die Begründung finden, dass die Java EE-Spezifikation besagt, dass sie Single-Threaded sein sollen.Aber ich kann den Grund nicht verstehen, warum dies so angegeben ist EINFACH GEWINDE?

Answer 1

Aufgrund des TX-Kontexts sind die SLSBs Single-Threaded. Principal ist beim Aufruf einer Bean-Instanz zugeordnet.Diese Beans werden gepoolt und, sofern die maximale Poolgröße nicht erreicht ist, in separaten Threads verarbeitet (abhängig vom Anbieter).

Wenn SLSBs Thread-sicher gestaltet wären, hätte jeder Aufruf wie ein Servlet doGet/Post mit Anforderungsinformationen mit Tx-Kontext, Sicherheitskontextinformationen usw. ausgesehen.Zumindest sieht der Code sauber aus (abhängig vom Entwickler).

Answer 2

Der Hauptgrund dafür, dass zustandslose Session-Beans Single-Threaded 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 er sich keine Gedanken über Synchronisierung oder Wiedereintritt in seine Geschäftslogik machen muss, da die Bean niemals in einem anderen Thread-Kontext aufgerufen wird.

Ich erinnere mich an die Argumentation, die in den Rezensionen der ursprünglichen EJB 1.0-Spezifikation diskutiert wurde.Ich würde mir den Abschnitt „Ziele“ in der Spezifikation ansehen.Sehen http://java.sun.com/products/ejb/docs.html für die Liste der Spezifikationen.