"Nothing is easy, though time gets you worrying, my friend, it's o.k." Jethro Tull Song. Danke dass ihr euch dieses Problems annimmst!👍🕯️🦄☕🍏💚😀 Dieses Problem und seine möglichen Lösungen regen mich dazu an, zur Verbesserung der Anschaulichkeit, eine Simulation/Animation dazu zu entwerfen.
Worin liegt der Vorteil, aus einer Transaktion plötzlich zwei zu machen? Wenn die Software auf den Status in der Datenbank reagiert, sollte der Status korrekt sein. Das kann ich mit dem Outbox Pattern nicht gewährleisten, da hier die Status auseinanderlaufen können. Wenn ich beim Ziel sowieso gezwungen bin, idempotent ausgelegt zu sein, dann kann ich gleich dabei bleiben, alles in einer Transaktion zu verarbeiten - erst Message erzeugen und dann das DB Upsert ausführen. Schlägt die Message fehl, überspringe ich die DB Aktion. Schlägt die DB Aktion fehl, schicke ich die Message mehrmals. Aber vielleicht übersehe ich auch was...
Ich habe meine Services so implementiert, wenn ein ungültiger Datensatz erkannt wird, dass ein Prozess gestartet wird, der es korrigiert. Jedoch versuche ich dies zu vermeiden solch eine Abhängigkeit einzubauen und bisher hatte ich nicht so häufig diese Problemstellung. Aber die vorgestellte Lösung ist cool und kannte ich noch nicht …
@@thenativeweb ein immutable ledger vereinfacht die Lösung: anstatt die Datenänderung an die Datenbank und an den subscriber zu senden abonnieren beide ein topic (und das muss nicht Kafka, sondern kann auch ein richtiges Pub Sub System wie z.B. Solace sein) . Hier kann man auch verschiedene Protokolle verwenden, die z.b. QoS Eigenschaften anbieten
[gr] Die Frage ist doch, wie Du das nachprüfst? Klar, in der Datenbank ist das einfach - aber in anderen Systemen nicht, weil die nicht darüber Buch führen, was sie verarbeitet haben und was nicht (zB dürfte es eher schwer werden, von einer Message-Queue zu erfahren, welche Messages schon zugestellt wurden, zumal das auch noch nichts darüber aussagt, ob sie vom Empfänger auch verarbeitet wurden).
Sehr gut und einfach erklärt. Vielen Dank :)
Sehr gut erklärt, danke!
Vielen lieben Dank 😊
Sehr sympathisch der Herr
[gr] Danke 😊
"Nothing is easy, though time gets you worrying, my friend, it's o.k." Jethro Tull Song.
Danke dass ihr euch dieses Problems annimmst!👍🕯️🦄☕🍏💚😀
Dieses Problem und seine möglichen Lösungen regen mich dazu an, zur Verbesserung der Anschaulichkeit, eine Simulation/Animation dazu zu entwerfen.
[gr] Merci 😊
Worin liegt der Vorteil, aus einer Transaktion plötzlich zwei zu machen? Wenn die Software auf den Status in der Datenbank reagiert, sollte der Status korrekt sein. Das kann ich mit dem Outbox Pattern nicht gewährleisten, da hier die Status auseinanderlaufen können.
Wenn ich beim Ziel sowieso gezwungen bin, idempotent ausgelegt zu sein, dann kann ich gleich dabei bleiben, alles in einer Transaktion zu verarbeiten - erst Message erzeugen und dann das DB Upsert ausführen. Schlägt die Message fehl, überspringe ich die DB Aktion. Schlägt die DB Aktion fehl, schicke ich die Message mehrmals.
Aber vielleicht übersehe ich auch was...
Ich habe meine Services so implementiert, wenn ein ungültiger Datensatz erkannt wird, dass ein Prozess gestartet wird, der es korrigiert. Jedoch versuche ich dies zu vermeiden solch eine Abhängigkeit einzubauen und bisher hatte ich nicht so häufig diese Problemstellung. Aber die vorgestellte Lösung ist cool und kannte ich noch nicht …
[gr] Freut mich, dass es eine Anregung war 😊
Habt ihr schon mal Apache Kafka ausprobiert? (produktiv)
[gr] Ja, sowohl intern als auch bei Kunden. Worauf willst Du hinaus?
@@thenativeweb ein immutable ledger vereinfacht die Lösung: anstatt die Datenänderung an die Datenbank und an den subscriber zu senden abonnieren beide ein topic (und das muss nicht Kafka, sondern kann auch ein richtiges Pub Sub System wie z.B. Solace sein) . Hier kann man auch verschiedene Protokolle verwenden, die z.b. QoS Eigenschaften anbieten
Warum kann man nicht einfach im nachhinein nochmals prüfen ob die Nachricht gespeichert und versendet wurde?
[gr] Die Frage ist doch, wie Du das nachprüfst? Klar, in der Datenbank ist das einfach - aber in anderen Systemen nicht, weil die nicht darüber Buch führen, was sie verarbeitet haben und was nicht (zB dürfte es eher schwer werden, von einer Message-Queue zu erfahren, welche Messages schon zugestellt wurden, zumal das auch noch nichts darüber aussagt, ob sie vom Empfänger auch verarbeitet wurden).
@@thenativeweb ok, danke. Kniflig 🙂
[gr] Gern geschehen ☺️