Die EJB 3.0-Spezifikation erlaubt keiner Geschäftsmethode einer Stateless-Session-Bean, neue Threads zu erstellen. Warum das? Was ist falsch daran, zusätzliche Worker-Threads zu erstellen, die nur rohe Berechnungen ausführen und niemals den App-Server aufrufen?
Nehmen wir an, meine Session-Bean implementiert einen Service, mit dem Benutzer Bilder hochladen können, und die Geschäftsmethode führt eine cpu-intensive Bildverarbeitung für diese Bilder durch. Dann kann es nur einen CPU-Kern verwenden, um diese Aufgabe zu erledigen, selbst wenn die Maschine 8 oder mehr Kerne hat? Wenn ich eine Bildverarbeitungsbibliothek eines Drittanbieters verwende, die intern Worker-Threads erstellt, würde ich auch die EJB-Spezifikationen verletzen, obwohl diese Bibliothek und diese Threads überhaupt nichts mit dem EJB-Container zu tun haben. Das scheint nicht richtig zu sein.
Was passiert, wenn ich die EJB-Regeln ignoriere und trotzdem einige Worker-Threads für die CPU-intensive Verarbeitung erstelle? Natürlich werden diese Threads niemals irgendwelche App-Server-Objekte berühren, und der Bean-Thread wird ihnen vor der Rückkehr beitreten. Kann noch etwas Schlimmes passieren?
Die EJB 3.0-Spezifikation erlaubt keiner Geschäftsmethode einer Stateless-Session-Bean, neue Threads zu erstellen. Warum ist das so?
Kurzfassung: Das Verwalten von Threads von EJBs ist nicht erlaubt, da dies das Ressourcenmanagement, das Transaktionsmanagement, die Sicherheit (technische Gründe) beeinträchtigen würde und auch, weil das EJB-Modell nicht fördern will (philosophischer Grund).
>Die EJB-Spezifikation sagt es so:
21.1.2 Programmiereinschränkungen
...
- Die Enterprise-Bean darf nicht versuchen, Threads zu verwalten. Die Enterprise-Bean darf nicht versuchen, einen Thread zu starten, zu stoppen, auszusetzen oder fortzusetzen oder die Priorität oder den Namen eines Threads zu ändern. Die Enterprise-Bean darf nicht versuchen, Thread-Gruppen zu verwalten.
Diese Funktionen sind für den EJB-Container reserviert. Wenn die Enterprise-Bean Threads verwalten würde, würde dies die Fähigkeit des Containers beeinträchtigen, die Laufzeitumgebung ordnungsgemäß zu verwalten.
(...) Wenn ich eine Bildverarbeitungsbibliothek eines Drittanbieters nutze, die intern Worker-Threads erstellt, würde ich auch gegen die EJB-Spezifikationen verstoßen, obwohl diese Bibliothek und diese Threads überhaupt nichts mit dem EJB-Container zu tun haben. Das scheint nicht richtig zu sein.
Was soll ich sagen, benutzen Sie keine EJBs, wenn Sie das nicht mögen.
Was passiert, wenn ich die EJB-Regeln ignoriere und trotzdem einige Worker-Threads für die CPU-intensive Verarbeitung erstelle? Natürlich werden diese Threads niemals irgendwelche App-Server-Objekte berühren, und der Bean-Thread wird ihnen vor der Rückkehr beitreten. Kann noch etwas Schlimmes passieren?
Ob diese Threads die App-Server-Objekte berühren oder nicht, spielt keine Rolle. Regeln sind Regeln, Sie wollen ihnen nicht folgen, Sie sind allein und das Verhalten ist nicht definiert. Einige Container sind möglicherweise permissiver und erlauben es, andere nicht, Ihre Anwendung wird nicht portierbar sein usw. Aber es ist immer noch explizit verboten.
Wenn Sie Threads standardmäßig "spawnen" möchten, verwenden Sie die WorkManager-API oder verwenden Sie JMS.
Dies ist eine bekannte Einschränkung, keine Threads in J2EE-Anwendungen zu verwenden. Anwendungsserver sollte sich um die parallele Ausführung des Programms kümmern
Ja, Sie können die EJB-Regeln ignorieren, können jedoch mit extrem unvorhersehbarem Verhalten konfrontiert werden .
In meinem vereinfachten Verständnis ist es so, als würde man ein Unternehmen leiten. Du bist der Boss (der Container), und es gibt einen Angestellten, der plötzlich 100 Leute aus heiterem Himmel anstellt, ohne irgendeine Notiz (die Bohne).
Aber Sie können immer noch Multithreading mit der @ Asynchronous Annotation durchführen (es gibt auch andere Möglichkeiten).
%Vor%Es gibt auch ein besseres Beispiel hier: Jboss Java EE-Container und ein ExecutorService
Tags und Links java multithreading java-ee ejb ejb-3.0