JDBC & DB Transaction für parallele Applikationen

Hallo zusammen,
ich habe ein Machbarkeitsproblem und weiß nicht mehr weiter.
Ich habe 2 PG-Datenbanken (DB_A, DB_B) und 2 Java-Applikationen (Appl_1, Appl_2), die parallel laufen sollen.

Die Appl_1 schreibt in DB_A in alle Tabellen beinah gleichzeitig und benutzt JTA. Die Transaktionen dauern manchmal mehrere Minuten.
Die Appl_2 will die Daten aus DB_A konsistent in die DB_B ‘kopieren’. Die Tabellen sind miteinander über FK verknüpft. Deshalb kann ich nicht einfach aus jeder Tabelle “alle vorhandenen” Daten kopieren, weil später gelesene Tabellen die Verweisen auf nicht existierende Daten beinhalten werden. Man kann Appl_1 nicht anhalten und Appl_1 und Appl_2 können nicht miteinander kommunizieren.

Gibt es die Möglichkeit über JDBC oder andere Framework die Daten in DB erkennen, bei denen die zugehörige JDBC Transaction noch nicht commited ist? So könnte ich z.B. die Daten nur aus den commited Transaktionen kopieren, das würde mein Problem lösen.

Für alle Ideen bin ich sehr dankbar.
myklynysh

Wäre das nicht eher ein Job für z.B. Slony?

Andreas

Wäre das nicht eher ein Job für z.B. Slony?

Möglicherweise gibt es dafür gute Tools. Beim ‘kopieren’ werden die daten auch ein wenig modifiziert: z.B. Byte-array-Daten(serialisierte Java-Objekte) werden in String ungewandelt. Dafür benutze ich Java-Klassen.

Wäre das mit Slony auch möglich?

Nein. Aber sowas kann auch die DB machen (vielleicht).

Andreas

Du solltest dich für den Anfang mit Two-Phase-Commit und Prepared Transactions beschäftigen. Das könnte eine Lösung für dein Problem sein.

Wenn nicht, muss man da wohl viel mehr Logik draufwerfen.

Du solltest dich für den Anfang mit Two-Phase-Commit und Prepared Transactions beschäftigen. Das könnte eine Lösung für dein Problem sein.

Ich fürchte, das wird nicht reichen. Ich kann Appl_1 nicht anfassen. Sie schreibt mit Hibernate in die Datenbank. Außerdem man möchte auch Postgres unabhöngig sein, d.h. nur über JDBC daraf zugreifen.

Es bleibt nur an Ansatz mit mehr Logik. Mir fehlt die Grundidee, wie ich es umsetzen kann.

Du wirst in einer Transaktion sowieso niemals Daten einer anderen Transaktion sehen wenn diese noch nicht committed sind.


Sie schreibt mit Hibernate in die Datenbank. Außerdem man möchte auch Postgres unabhöngig sein, d.h. nur über JDBC daraf zugreifen.

Two phase commit ist Bestandteil von JTA und damit unabhängig von Postgres.

Aber wenn Du die Anwendung nicht ändern kannst, dann wird Dir das wirklich nicht helfen.

Ich sehe die einzige Möglichkeit über Trigger:

In DB 1 legst Du Trigger auf alle Tabellen die Du “replizieren” möchtest. Im Trigger schreibst Du in eine weitere Tabelle die Datensätze die geändert wurden. Mittles LISTEN/NOTIFY beobachtest Du diese Tabellen und schreibst die geänderten Datensätze in die Ziel-DB.

Letztendlich ist das aber genau das was auch Lösungen wie Slony machen.

Da hätten wir Problem Nummer 1. Die Datenbank soll richten, was die Anwendung nicht hinbekommt.


Sie schreibt mit Hibernate in die Datenbank.

Oh, und da wäre schon Problem Nummer 2.


Na ja, zum Rest wurde schon was gesagt. Das ganze auf Datenbankebend zu lösen halte ich für gewagt, da die Anwendung schon mit mehreren Datenbanken arbeitet. Das geht in irgendeiner Konstellation immer schief.