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
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
Zuletzt bearbeitet:
