SEQUENCE Problem beim ROLLBACK

[grantefux]

Wir nutzen das DB2 Objekt SEQUENCE, um einen Nummernkreis zu verwalten. Alles funktioniert wunderbar, nur bei einem ROLLBACK wird die mit NEXT VALUE ermittelte nächste Nummer nicht zurückgesetzt.

Laut IBM i information center können SEQUENCES nicht unter Transaktionskontrolle gesetzt werden:

"Sequences are not under transaction control. Executing a ROLLBACK statement does not affect the current value generated and consumed by executing a NEXT VALUE expression."

Hat jemand ein ähnliches Problem und eine Lösung, um eine Art ROLLBACK der fortlaufenden Nummer zu erreichen?

[Fuerchau]

Eine Sequence darf nicht per Rollback zurückgesetzt werden !

Da diese ja von mehreren Job's in separaten Transaktionen hochgezählt werden kann, würde ein Rollback einer einzelnen Transaktion den Zähler für die anderen Transaktionen verfälschen bzw. unbrauchbar machen.

Wenn du sicher bist, dass du die Sequenz nur alleine benötigst, kannst du diese mit ALTER SEQUENCE selber zurücksetzen.

[BenderD]

... da braucht man eine eigene getKey(Tabelle) mit einer entsprechenden Key Tabelle. Falls man die dann in Commit einbezieht, serialisiert das natürlich das schreiben von Sätzen (sprich: geht immer nur nacheinander).

D*B

[grantefux]

Ich müsste auf jeden Fall garantieren, dass der Nummernkreis innerhalb der Tabelle, welche eine fortlaufende Nummer bezieht und in ein Feld schreibt, lückenlos ist. Mir ist klar, dass ich mit ALTER SEQUENCE die Sequenz selber zurücksetzen kann. Was passiert allerdings, wenn die Transaktion vor dem ALTER SEQUENCE Statement aus irgend einem Grund abbricht? Dann habe ich eine Lücke im Nummernkreis. Ich muss hierzu noch anmerken, dass nicht jeder Datensatz in meiner Tabelle die oben erwähnte fortlaufende Nummer bezieht, sondern nur ganz bestimmte Datensätze, welche dann eben in einem lückenlosen, geschlossenen Nummernkreis stehen müssen.

[Fuerchau]

Dann musst du Dieters Vorschlag aufnehmen und die Nummernvergabe über einen eigenen Tabellensatz durchführen, der natürlich auch journalisiert werden muss.
Im Falle eines Rollbacks werden eben auch diese zurückgedreht.

Bedenke aber, dass dieser Nummern-Satz bis zum Commit/Rollback gegen Updates aus anderen Transaktionen gesperrt bleibt und ggf. beim Update dann ein Timeout (default 60 Sekunden) auftritt!

Da auch ein ALTER SEQUENCE nicht journalisiert wird, liegt es rein an dir zu überlegen, was passieren kann.
Berücksichtigen musst du lediglich, ob deine Transaktionen quasi parallel von mehreren Job's durchgeführt werden können.

[BenderD]

... lückenlos lässt sich mit sequence nicht erzwingen.
eine getKey als User defined function unter commit sollte es tun (da gibt es was auf meiner OpenSource Seite).
Falls man die Serialisierung vermeiden will und nur Lückenlosigkeit braucht, könnte man auch eine Neuvergabe der Lücken, in Betracht ziehen. Da sich das Ganze nach Revisonsanforderung anhört, muss man das mit denen abstimmen!!!

D*B

Ich müsste auf jeden Fall garantieren, dass der Nummernkreis innerhalb der Tabelle, welche eine fortlaufende Nummer bezieht und in ein Feld schreibt, lückenlos ist. Mir ist klar, dass ich mit ALTER SEQUENCE die Sequenz selber zurücksetzen kann. Was passiert allerdings, wenn die Transaktion vor dem ALTER SEQUENCE Statement aus irgend einem Grund abbricht? Dann habe ich eine Lücke im Nummernkreis. Ich muss hierzu noch anmerken, dass nicht jeder Datensatz in meiner Tabelle die oben erwähnte fortlaufende Nummer bezieht, sondern nur ganz bestimmte Datensätze, welche dann eben in einem lückenlosen, geschlossenen Nummernkreis stehen müssen.

[grantefux]

Alles klar, danke für eure Ratschläge!