XA oder nicht-XA für die JMS-und DB-Betrieb

Ich bin ziemlich neu in der XA und non-XA Welt. Meine Anforderung ist, Lesen Sie eine Nachricht aus der Warteschlange, bis es eine NICHT-Nachricht. Für jede Nachricht in der Warteschlange, gehen Sie zu den DB-und einige Transaktionen wie select, insert, update.

Ist das möglich mit nicht-XA-datasource? Ich bin derzeit mit XA-datasource-aber gelernt, dass es teuer ist und die Leistung Treffer.

Jede Hilfe dankbar! Dank

  • Sie sollte wohl erklären, wie die queue verwaltet wird, was für ein Produkt verwendet wird. Einige db-Anbieter bieten auch queueing-Lösungen, die Ihr Leben einfacher machen wird.
InformationsquelleAutor user726579 | 2014-01-17
  1. 4

    Wenn Sie brauchen, um in Ihrer Transaktion, die sowohl die Interaktion mit einem JMS-Verbindungs - (d.h. senden oder empfangen einer Nachricht) und eine Verbindung mit einer Datenbank, indem Sie eine db-Verbindung dann müssen Sie auf jeden Fall eine XA-datasource seit Ihrer Transaktion ist ein zwei-Phasen-commit (2PC) Transaktion.

    In einem zwei-Phasen-commit-Transaktion, die Sie entweder übernehmen Sie die änderungen auf alle Ihre Ressourcen (in deinem Fall JMS-und DB-Ressourcen) oder rollback alle änderungen, wenn etwas schief geht mit Ihnen.

    Um dies zu tun, müssen Sie eine Verbindung zu einem XA-fähige datasource.
    Darüber hinaus werden in einem Java EE container, JMS-Verbindungen sollte es schon sein, XA-Fähigen.

    InformationsquelleAutor trikelef
  2. 2

    Betrachten 1.5 phase-commit. Grundsätzlich:

    • Schritt 1: übertragen Sie die DB-Transaktion
    • Schritt 2: übertragen Sie die JMS-Transaktion.

    Möglicher Fehler-Szenarien:

    1. DB-Transaktion fehl.
    2. DB-Transaktion erfolgreich JMS-Transaktion schlägt fehl.
    3. alle erfolgreich.

    Nicht 1, noch 3 Blätter Ihr system in einem inkonsistenten Status. Im Fall von 1, brauchen Sie nur, die Mitteilung zu senden.

    Behandeln Szenario 2. Sie müssen sich vorstellen, Dubletten-check, um Ihr system. Also im wesentlichen Ihre Transaktions-management Aussehen würde, ähnlich wie diese:

    //pseudo code
if (isDublicate(message))
   commitJMSTransaction();
else
   doYourBusinessLogic();
   doYourDBOperation();
   commitDBTransaction();
   commitJMSTransaction();

    Wenn die JMS-Transaktion fehlschlägt, Ihre message broker wird erneut versuchen, die Nachricht zu senden (oder Sie müssen erneut manuell je nach broker-setup), aber du Dublettenprüfung wird das erkennen und entfernen Sie es aus der Warteschlange.

    InformationsquelleAutor forgacan
  3. 2

    Geben Ihnen eine Idee von, XA und NON-XA-transations erkläre ich es kurz,
    Eine XA-Transaktion ist eine "global transaction".
    Eine nicht-XA-Transaktion ist eine "Transaktion".

    Einer XA-Transaktion umfasst eine Koordinierung der Transaktions-manager, der mit einer oder mehreren Datenbanken (oder anderen Ressourcen, wie JMS) alle beteiligten in einem einzigen globalen Transaktion. Wenn eine Verbindung zu mehreren Datenbanken dann ist XA.

    Nicht-XA-Transaktionen haben keine transaction coordinator, und eine einzelne Ressource ist dabei alle seine Transaktion ist die Arbeit selbst. Diese haben nur eine Datenbank als Ressource.

    InformationsquelleAutor eight Stacker
  4. 0

    XA garantiert, dass eine Nachricht überein 1 und nur 1 DB-Transaktion.
    Denken wir daran, was geschehen, ohne dass XA (nur eine von vielen möglichen Situationen):

    1. Die MDB wählen Sie eine Nachricht
    2. Die MDB ausführen einer DB-job (sagen wir mal, dass alles gut gehen... keine Ausnahmen)
    3. Der application-server jdk Absturz aus irgendeinem Grund oder es liegt ein Netzwerkfehler während der MDB-thread noch läuft
    4. Einfachheit halber betrachten wir, dass der server neu gestartet: da die MDB nicht commit der Transaktion, aus diesem Grund ist die Nachricht noch in der Warteschlange.
    5. Anderen MDB die Nachricht erhalten und wiederholen Sie den DB-Transaktion.

    Für unser Glück, XA existieren! 🙂
    Aus den Vorstellungen der Sicht es gibt Kosten zu bezahlen, aber immer die Qualität (service -) Kosten hat!

    • Sie sind mehrere Annahmen hier, die sind nicht unbedingt korrekt: die Datenbank und das queueing-system müssen beide unterstützen das XA-Protokoll.
    • Diese Annahmen sind in der Frage. Er sagt, er kann wählen zwischen XA-datasource-und non-XA-aber er ist besorgt über die Veranstaltungen. WebSphere-Messaging unterstützt XA, es ist eine Anforderung der J2EE-Spezifikationen. Ich zeigte nur ein Beispiel, wie die XA hilft.
    InformationsquelleAutor dmarrazzo
Schreibe einen Kommentar