Wie erwähnt, JPA <> EJB, sie sind nicht einmal verwandt. EJB 3 nutzt JPA, aber das ist es auch schon. Wir haben eine Menge Dinge, die JPA verwenden, die EJB nicht einmal nahe kommen.
Ihr Problem ist nicht die Technologie, es ist Ihr Design.
Oder sollte ich sagen, Ihr Design ist nicht einfach auf ziemlich jedem modernen Rahmen passen.
Insbesondere versuchen Sie, Transaktionen über mehrere HTTP-Anforderungen am Leben zu erhalten.
Natürlich ist jedes gängige Idiom, dass jede Anfrage in sich eine oder mehrere Transaktionen ist, anstatt jede Anfrage ein Teil einer größeren Transaktion zu sein.
Es gibt auch offensichtliche Verwirrung, wenn Sie den Begriff "staatenlos" und "Transaktion" in der gleichen Diskussion verwendet, da Transaktionen von Natur aus stateful sind.
Ihr großes Problem ist einfach Ihre Transaktionen manuell zu verwalten.
Wenn die Transaktion über mehrere HTTP-Anfragen läuft, und diese HTTP-Anfragen "sehr schnell" ausgeführt werden, dann sollten Sie nicht wirklich ein echtes Problem haben, speichern Sie, dass Sie müssen Stellen Sie sicher, dass Ihre HTTP-Anforderungen dieselbe Datenbankverbindung verwenden, um die Transaktionsfunktion Datenbanken zu nutzen.
Das heißt, in einfachen Worten, erhalten Sie eine Verbindung mit der DB, stopfen Sie es in der Sitzung, und stellen Sie sicher, dass für die Dauer der Transaktion alle Ihre HTTP-Anfragen nicht nur die gleiche Sitzung durchlaufen so dass die eigentliche Verbindung noch gültig ist. Insbesondere glaube ich nicht, dass es eine JDBC-Verbindung von der Stange gibt, die Failover oder Lastausgleich von einer Maschine zur anderen überlebt.
Also, einfach, wenn Sie DB-Transaktionen verwenden möchten, müssen Sie sicherstellen, dass Sie die gleiche DB-Verbindung verwenden.
Nun, wenn Ihre lang laufende Transaktion "Benutzerinteraktionen" innerhalb hat, d. H. Sie starten die DB-Transaktion und warten auf den Benutzer "etwas zu tun", dann ist dieses Design ganz einfach falsch. Das wollen Sie nicht tun, da Transaktionen mit langer Lebensdauer, besonders in interaktiven Umgebungen, einfach schlecht sind. Wie "Crossing The Streams" schlecht. Tu es nicht. Batch-Transaktionen sind unterschiedlich, aber interaktive langlebige Transaktionen sind schlecht.
Sie möchten Ihre interaktiven Transaktionen so kurz wie möglich halten.
Jetzt, wenn Sie nicht sicherstellen können, dass Sie die gleiche DB-Verbindung für Ihre Transaktion verwenden können, dann, herzlichen Glückwunsch, können Sie Ihre eigenen Transaktionen implementieren. Das bedeutet, dass Sie Ihre System- und Datenflüsse so gestalten müssen, als hätten Sie keine Transaktionsfunktionalität am Backend.
Das bedeutet im Wesentlichen, dass Sie mit Ihrem eigenen Mechanismus kommen müssen, um Ihre Daten zu "committen".
Ein guter Weg, dies zu tun wäre, wo Sie Ihre Daten schrittweise in einem einzigen "Transaktion" -Dokument aufbauen, dann füttern das Dokument zu einer "Speichern" -Routine, die viel von der eigentlichen Arbeit macht. Sie könnten beispielsweise eine Zeile in der Datenbank speichern und sie als "nicht gespeichert" kennzeichnen. Sie tun das mit all Ihren Zeilen und rufen schließlich eine Routine auf, die alle Daten durchläuft, die Sie gerade gespeichert haben, und markiert sie alle als "gespeichert" in einem einzelnen Transaktion Mini-Batch-Prozess.
In der Zwischenzeit "ignoriert" all Ihre anderen SQL-Daten Daten, die nicht "gespeichert" werden. Werfen Sie einige Zeitstempel ein und lassen Sie einen Reaper-Prozess auffliegen (wenn Sie wirklich Ärger machen wollen - es könnte tatsächlich billiger sein, tote Zeilen in der DB zu belassen, hängt vom Volumen ab), diese toten "ungespeicherten" Zeilen, wie diese sind "nicht genehmigte" Transaktionen.
Es ist nicht so schlimm wie es klingt. Wenn Sie wirklich eine zustandslose Umgebung wollen, so wie es sich für mich anhört, dann müssen Sie so etwas tun.
Bedenken Sie, in all dem hat die Persistenz Tech wirklich nichts damit zu tun. Das Problem ist, wie Sie Ihre Transaktionen verwenden, anstatt die Technologie so sehr.
Muss Ihr Paradigma ein ORM sein? – dacracot