# mal wieder eine Frage zu parallelen Transaktionen..



## JanHH (3. Mai 2011)

Hallo,

wie löst man folgendes Problem (mit JPA/Hibernate)?

In einer Tabelle ändert eine Transaktion eine Reihe von Werten, z.B. wird in 100 Zeilen der Wert einer Spalte von "1" auf "2" gesetzt. Während diese Transaktion abläuft, ändert eine andere Transaktion einen dieser Werte (also eine der 100 Zeilen, die von der ersten Transaktion beeinflusst werden) von "1" auf "3".

Ich bin eher ein Anfänger im Bereich der Datenbanken, aber nach dem was ich bisher so weiss gibt es verschiedene locking-Varianten, die immer dazu führen, dass eine der beiden Transaktionen nicht ausgeführt wird (bzw. rollback), je nachdem, welche zuerst committed. Das gewünschte Verhalten ist allerdings, je nach Reihenfolge der Commits:

T1 commited vor T2 (was wohl eher nicht so oft vorkommen dürfte, da T1 generell viel länger läuft): Alle 100 Werte werden auf 2 gesetzt, ob T2 ausgeführt wird (also der Wert 2 oder 3 ist), ist egal

T2 commited vor T1: T1 darf nicht ge-rollbacked werden, was aber das ist, was ich befürchte (weil halt eine Zeile schon von einer anderen transaktion geändert wurde, wobei es da sicher auch eine Rolle spielt, ob T1 oder T2 vorher anfangen). Wenn T1 vor T2 startet, müsste es ja mit einem select for update gehen (und T2 würde beim Versuch, eine bereits "selectete" Zeile zu ändern, abgebrochen werden), im umgekehrten Fall sehe ich das Problem. T1 startet nach T2, T2 hat die Zeile bereits selected, T1 wird abgebrochen beim Versuch, zu committen, und alle 100 Werte bleiben unbeeinflusst.

Also wie auch immer der zeitliche Ablauf ist, T1 soll definitiv ausgeführt werden, T2 ist dann ggf. egal. Kann man den Transaktionen Prioritäten geben (nach dem Motto, T1 gewinnt immer über T2)? Oder wie löst man das?

Gruß+Danke
Jan


----------



## henpara (5. Mai 2011)

> Also wie auch immer der zeitliche Ablauf ist, T1 soll definitiv ausgeführt werden, T2 ist dann ggf. egal. Kann man den Transaktionen Prioritäten geben (nach dem Motto, T1 gewinnt immer über T2)? Oder wie löst man das?
> 
> Gruß+Danke
> Jan


Wenn ich dich jetzt richtig verstanden habe wäre wohl die einfachste Methode der Tabelle noch eine Spalte hinzuzufügen und die gesetzt wird, wenn T1 ausgeführt wird. T2 schaut dann ob diese neue Spalte von T1 gesetzt wurde (zB auf 1) und der update Befehl bekommt eben noch ein where neuespalte != 1.


----------



## JanHH (8. Mai 2011)

Aber da sehe ich keine wirklich Veränderung der Struktur drin. In diesem Fall ist halt noch eine weitere Spalte von Änderungen betroffen, aber alle Probleme parallel laufender Transaktionen werden dadurch nicht behoben. Hab allerdings schon eine andere Idee, wie ich das lösen kann; so dass T2 nur liest, die von T2 vorgenommenen Änderungen werden in einer anderen Tabelle gespeichert (die wiederum von T1 unbeeinflusst bleibt).


----------

