Wir verwenden Cookies, um unsere Website effizienter und benutzerfreundlicher zu machen. Erfahren Sie in unserer Datenschutzerklärung mehr darüber, wie wir Cookies verwenden.

Transaktionale Hintergrundprozesse

Hintergrundprozesse die auf einem externen, zweiten Datenspeicher, aufbauen müssen nach einem bestimmten Schema implementiert sein um Robustheit zu erlangen.

Wenn die Zeile queue_job(stuff) in folgendem Beispiel direkt in den zweiten Datenspeicher schreibt gibt es ein Problem. Wenn Sidekiq wie empfohlen verwendet wird ist die Problematik immer da.

DB.transaction do
  stuff = do_and_save_stuff_to_database
  queue_job(stuff)
  do_other_stuff
end

Was ist das Problem?

Es könnte in do_other_stuff zu einem Fehler kommen der die Transaktion abbricht. In diesem Fall gibt es einen Hintergrundprozess der sich auf nicht vorhandene Daten bezieht.

Alternativ könnte der Hintergrundprozess sofort abgearbeitet werden bevor die Daten in den primären Datenspeicher geschrieben wurden.

Wenn der Hintergrundprozess nach der Transaktion angestoßen wird gibt es ein weiteres Fehlerszenario. Die Transaktion schreibt Daten in den primären Datenspeicher um dann später zu merken dass der Hintergrundprozess nicht angestoßen werden konnte.

Alle diese Situation sind nicht wünschenswert. Eine mögliche Lösung wird in Transactionally Staged Job Drains in Postgres aufgezeigt.

Literaturverzeichnis