Warum Stateless Session Beans Pool?

Question

Statuslose Beans in Java behalten ihren Status zwischen zwei Aufrufen vom Client nicht bei. Kurz gesagt, wir könnten sie als Objekte mit Geschäftsmethoden betrachten. Jede Methode akzeptiert Parameter und gibt Ergebnisse zurück. Wenn die Methode aufgerufen wird, werden einige lokale Variablen im Ausführungs-Stack erstellt. Wenn die Methode zurückkehrt, werden die Locals aus dem Stapel entfernt und wenn einige temporäre Objekte zugewiesen wurden, werden sie sowieso als Müll gesammelt.

Aus meiner Sicht unterscheidet sich das nicht von Aufrufmethode derselben einzelnen Instanz durch separate Threads. Warum kann ein Container also keine Instanz einer Bean verwenden, anstatt mehrere davon zu bündeln?

Answer 1

Pooling macht mehrere Dinge.

Eins, mit einer Bean pro Instanz, sind Sie garantiert Threads sicher (Servlets, zum Beispiel, sind nicht Thread sicher).

Zwei, reduzieren Sie alle mögliche Startzeit, die eine Bean haben könnte. Während Session Beans "staatenlos" sind, müssen sie nur staatenlos gegenüber dem Kunden sein. In EJB können Sie beispielsweise mehrere Serverressourcen in eine Session Bean einspeisen. Dieser Status ist für die Bean privat, aber es gibt keinen Grund, warum Sie ihn nicht vom Aufruf zum Aufruf halten können. Durch das Pooling von Beans reduzieren Sie diese Suchvorgänge so, dass sie nur dann stattfinden, wenn die Bean erstellt wird.

Drei, Sie können Bohnen Pool als Mittel zur Drosselung des Verkehrs verwenden. Wenn Sie nur 10 Bohnen in einem Pool haben, werden Sie höchstens 10 Anfragen gleichzeitig bearbeiten, der Rest wird in die Warteschlange gestellt.

Answer 2

Lebenszyklus der Stateless-Session-Beans sind Doesnot exist, Passive und MethodReady (passiv oder inaktiv) state.To optimieren on perormance, anstatt die Bean durch alle von create zu Method Ready State zu durchlaufen, verwaltet Container die Bean zwischen aktiv und passive Zustände durch die Container-Callbacks - ejbActivate() und ejbPassivate() dort durch Verwalten des Bean-Pools.

sreenut

Answer 3

Pooling verbessert die Leistung.

Eine einzelne Instanz, die alle Anfragen/Threads behandelt, würde zu einer Menge von Konflikten und Blockierungen führen.

Da Sie nicht wissen, welche Instanz verwendet wird (und mehrere Threads gleichzeitig eine Instanz verwenden können), müssen die Beans sicher sein.

Der Container kann die Poolgröße basierend auf der tatsächlichen Aktivität verwalten.

Answer 4

Die Transaktionalität des Java EE-Modells verwendet den Threadkontext zum Verwalten des Transaktionslebenszyklus.

Diese Vereinfachung ist vorhanden, sodass es nicht erforderlich ist, eine bestimmte Schnittstelle für die direkte Interaktion mit dem UserTransaction-Objekt zu implementieren. Wenn die Transaktion aus dem InitialContext abgerufen (oder in die Session-Bean eingefügt) wird, wird sie zur Wiederverwendung an eine Thread-lokale Variable gebunden (z. B. wenn eine Methode in Ihrer Stateless Session-Bean eine andere Stateless Session-Bean aufruft, die ebenfalls eine injizierte Transaktion verwendet).)