In einer traditionellen n-Tier-Web-App mit Servlets für Weblayer und ejbs (2.0) für Biz-Layer, was ist der Grund dafür, das Servlet-Modell multi-threaded und das ejb-Modell single-threaded?
. Es gibt nur eine Servlet-Instanz für alle Anfragen, aber für ejbs gibt es für jede Anfrage eine neue Bean-Instanz aus dem Bean-Pool.Multi-Thread-Servlet; single threaded ejb
Es gibt tatsächlich nur eine Instanz für eine spezifische Servlet, da sie zustandslos sein sollen. In der Praxis ist das nicht immer der Fall, aber sei es so.
Es gibt jedoch mehrere Instanzen von Stateless session beans (SLSB), und diese sind gepoolt.
Durch ihre Definition stateless session beans sind zustandslos, so auf der Oberfläche scheint wie ein Paradoxon. Die Dinge sind, dass während stateless session beans zustandslos sind in Bezug auf einzelne Anrufe an sie gemacht werden, sie in der Tat sehr oft Zustand haben.
Dieser Zustand ist in Form von Verweise auf andere Ressourcen. Die JPA entity manager, die nicht Thread-Safe ist, ist ein Paradebeispiel hier. Während eines einzelnen Anrufs an eine stateless session bean muss der Anrufer exklusiven Zugriff auf diese Ressource haben. Wenn der Anruf zurückkehrt, kann der nächste Anrufer exklusiven Zugriff haben, usw.
Wenn eine einzelne Instanz verwendet wurde, dann müssten alle Anrufer aufeinander warten (was natürlich für die Leistung tötet), oder sie würden Zugriff auf diese einzelne Instanz gleichzeitig haben. Im letzteren Fall muss der Bean-Implementierer die nicht thread-sicheren Ressourcen wie die entity manager manuell sperren, die oft spröde, fehleranfällig ist und am Ende immer noch dazu führt, dass die Caller aufeinander warten.
Um die Leistung zu verbessern und trotzdem die Sicherheitsgarantie zu haben, werden mehrere Instanzen verwendet.
Diese Instanzen werden dann gepoolt und wiederverwendet, anstatt für jede Anforderung neu erstellt zu werden, da das Auffinden, Initialisieren und Injizieren aller erforderlichen Abhängigkeiten der Bean möglicherweise zeitaufwendig sein kann.
All dies bedeutet automatisch auch, dass wenn Sie einen Entity Manager oder andere nicht Thread-sichere Ressource in ein Servlet injizieren (was erlaubt ist), können Sie auf Probleme stoßen. Dies ist eine kleine Lücke in der Java-EE-Architektur, die natürlich einfach durch die Verwendung von Stateless-Session-Beans umgangen werden kann.
Ich denke, dass Servlets in der Regel dünne Fassade der schweren Logik in EJBs implementiert. Servlets sollten zustandslos sein und daher gibt es keinen Grund, mehr als eine Instanz desselben Servlets zu erstellen.
Wenn Sie nur Stateless Beans verwenden, denke ich, dass es keinen Grund gibt, mehr als eine Instanz zu haben. Stateful EJBs haben State und daher benötigen Sie Instanz pro gleichzeitige Anfrage.
Ich hoffe, ich habe nicht gesagt, Schwachsinn.
SLSB haben mehr als eine Instanz pro JVM..Die Anzahl der Instanzen ist im Bean-Pool konfiguriert – Victor
Vielen Dank! Wenn der SLSB also nicht auf EntityManager zugreift, kann er multi-threaded sein (d. H. Nur 1 Instanz)? – Victor
Mehr oder weniger. Wenn dies der Fall wäre, würden Sie ** nicht ** die @Stateless-Annotation verwenden, sondern die @Singleton. Dann gibt es nur eine Instanz Ihrer EJB-Bean.Sie können mit zusätzlichen Annotationen kontrollieren, ob mehrere Threads gleichzeitig auf einen solchen EJB zugreifen dürfen (wie in einem regulären Servlet) oder aufeinander warten müssen (wenn Methoden synchronisiert werden). –