Lieferung der JMS -Nachricht, bevor die Transaktion festgelegt wird

Question

Ich habe ein sehr einfaches Szenario mit a Datenbank und ein JMS auf einem Anwendungsserver (Glassfish). Das Szenario ist tot einfach:

1. an EJB inserts a row in the database and sends a message.
2. when the message is delivered with an MDB, the row is read and updated. 

Das Problem ist, dass manchmal die Die Nachricht wird vorgestellt, bevor der Einsatz begangen wurde in der Datenbank. Dies ist tatsächlich verständlich, wenn wir das 2 -Phasen -Commit -Protokoll betrachten:

1. prepare JMS
2. prepare database
3. commit JMS
4. ( tiny little gap where message can be delivered before insert has been committed)
5. commit database

Ich habe dieses Problem besprochen mit anderen, aber die Antwort war immer: "Seltsam, es sollte aus der Box funktionieren".

Meine Fragen sind dann:

• Wie könnte es außerhalb der Schachtel funktionieren?
• Mein Szenario klingt ziemlich einfach, warum gibt es nicht mehr Leute mit ähnlichen Problemen?
• Mache ich etwas falsch? Gibt es eine Möglichkeit, dieses Problem richtig zu lösen?

---

Hier sind ein bisschen mehr Details zu meinem Verständnis des Problems:

Dieses Timing -Problem besteht nur, wenn der Teilnehmer in dieser Reihenfolge behandelt wird. Wenn der 2PC die Teilnehmer in umgekehrter Reihenfolge behandelt (zuerst Datenbank, dann Message Broker), sollte dies in Ordnung sein. Das Problem trat zufällig, aber vollständig reproduzierbar.

Ich fand keine Möglichkeit, die Reihenfolge der Teilnehmer in den verteilten Transaktionen in den Spezifikationen JTA, JCA und JPA weder in der Glassfish -Dokumentation zu kontrollieren. Wir könnten davon ausgehen, dass sie in die verteilte Transaktion gemäß der Reihenfolge eingetragen werden, wenn sie verwendet werden, aber mit einem ORM wie JPA ist es schwierig zu wissen, wann die Daten gespült werden und wann die Datenbankverbindung wirklich verwendet wird. Irgendeine Idee?

Answer 1

Sie erleben den klassischen XA 2-PC-Rennzustand. Es geschieht in Produktionsumgebungen.

Es kommen 3 Dinge in mich in den Sinn.

1. Letzte Agentenoptimierung, wobei JDBC die Nicht-XA-Ressource ist. (Verlieren Sie die Wiederherstellungssemantik)
2. Habe jMS-Zeit-zu-Auslieferung. (Absichtlich Echtzeit verlieren)
3. Erstellen Sie Wiederholungen in JDBC -Code. (Am wenigsten Einfluss auf die Funktionalität)

Weblogic hat diese LLR -Optimierung dieses Problem und gibt Ihnen alle XA -Garantien.