Spring Transaction Propagation Überblick

Nutzt man das Transaktionsmanagement in Spring, kann man als Entwickler über die Propagation einer Transaktion (Eigenschaft z.B. auf der Annotation) bestimmen, wie die aufgerufenen Methoden in Bezug auf die Transaktion gekapselt werden. Verschachtelt, oder in einer großen Transaktion, man hat hier viele Freiheiten. Ich möchte nun die verschiedenen Ausprägungen von Propagation vorstellen und dabei anmerken wie sich diese bei einer Verschachtelung auswirken.


Transaction Propagation – Ein Überblick

Nutzt man das Transaktionsmanagement in Spring, kann man als Entwickler über die Propagation einer Transaktion (Eigenschaft z.B. auf der Annotation) bestimmen, wie die aufgerufenen Methoden in Bezug auf die Transaktion gekapselt werden. Verschachtelt, oder in einer großen Transaktion, man hat hier viele Freiheiten. Ich möchte nun die verschiedenen Ausprägungen von Propagation vorstellen und dabei anmerken, wie sich diese bei einer Verschachtelung auswirken.

REQUIRED

Logik unter REQUIRED nutzt die selbe Transaktion wie eine aufrufende Logik, wenn diese bereits innerhalb einer Transaktion läuft. Wenn noch keine Transaktion vorhanden ist, wird eine neue gestartet. Als Beispiel nehmen wir die Logik OUTER und INNER, beide mit Propagation REQUIRED. OUTER und INNER sind gekoppelt, sprich OUTER nutzt die Funktionalität INNER. Der Aufruf von OUTER erzeugt also eine neue Transaktion, da noch keine vorhanden ist. Nun ruft OUTER die Logik von INNER auf. Es existiert bereits eine laufende Transaktion, daher nutzt INNER diese. Wird nun innerhalb von INNER ein Rollback verursacht, kann auch OUTER nicht mehr Commiten und unterliegt einem Rollback.

REQUIRES_NEW

Kennzeichnet Logik die immer innerhalb einer neuen Transaktion ausgeführt wird. Nehmen wir wieder an OUTER hat eine Transaktion und ruft INNER, welches die Propagation REQUIRES_NEW aufweist, auf, sind diese beiden Transaktionen distinkt. So in INNER ein Rollback erfolgt, bekommt die Transaktion OUTER davon nichts mit und umgekehrt. Während INNER ausgeführt wird ist die Transaktion von OUTER pausiert.

NESTED

Nested Logik nutzt die selbe Transaktion wie der Aufrufer, jedoch werden Savepoints genutzt, um die innere Transaktion von der Äußeren unabhängig(er) zu machen. In der inneren Transaktion kann so ein Rollback erfolgen bis zurück in die äußere Transaktion, ohne dass dieser Teil ebenfalls einem Rollback unterliegt.

MANDATORY

Kennzeichnet Logik, die eine bereits geöffnete Transaktion voraussetzt. Wird sie aufgerufen ohne einer laufenden Transaktion wird eine Exception vom Container geworfen.

NEVER

Beschreibt Logik, die in keiner Transaktion ausgeführt werden darf. Erfolgt dennoch ein Aufruf aus einer Transaktion heraus wird eine Exception vom Container geworfen.

NOT_SUPPORTED

Logik wird hierbei außerhalb der Transaktion aufgerufen. Ist eine Transaktion bereits vorhanden, wird sie für den Aufruf der Logik pausiert.

SUPPORTS

Wenn bereits eine offene Transaktion vorhanden ist, wird die Logik in dieser ausgeführt. Ist keine vorhanden, wird die Logik auch ohne Transaktion durchlaufen.

In diesem Sinne:

@Transactional(propagation=Propagation.REQUIRES_NEW)
public void haveSomeFun(User user) {
    // TODO have fun
}

Ähnliche Artikel:

Autor: Thomas Pummer

Thomas Pummer ist Softwareentwickler an der Universität Wien. In seiner Freizeit betreut er das Open Source Projekt TrayRSS und werkt an diversen anderen kleinen Projekten. Er ist sehr interessiert an Open Source und Webentwicklung und testet gern neue Programmiersprachen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*