Stored Procedure & Functions unter Transaktionskontrolle setzen

[BenderD]

... eigentlich müssten die defaults passen, hast du die Connection richtig eingerichtet?

D*B

Ok.
Muss ich dazu auch irgendwelche Options in der STP setzen?

Hab nämlich nach dem Aufruf der STP ein rollback im Java-Programm versucht, die Updates der STP wurden aber nicht zurückgesetzt.

[Martin82]

Habs jetzt auch mit einer Test-STP probiert. Folgender Code:

create procedure test_cc()
language sql
begin

declare exit handler for sqlexception rollback;

insert into test values(1,'');
/* Dies löst einen SQL0803 aus (Doppelter Schlüsselwert)*/
insert into test values(1,'');

commit;

end;

Den Aufruf hab ich über RunSQLScripts vom System i Navigator gemacht. JDBC-Settings: Cursor stability(*CS)

Theoretisch müsste dann ja das erste INSERT zurückgesetzt werden oder hab ich da einen Denkfehler? Es klappt nicht. Auch nicht wenn ich nach dem Aufruf der STP explizit ein rollback ausführe...

[andreaspr@aon.at]

schau mit dem befehl DSPPGM test_cc was in den beschreibungen unter COMMIT-Steuerung drinnen steht.
wenn *NONE angegeben ist, würde ich beim erstellen der SP (wie von mir vorhin beschrieben) den eintrag angeben.

[BenderD]

... erst mal würde ich das nicht mit Oops Nerv testen, da sieht man zu wenig und außerdem ist das Teil buggy.
Was hast du jetzt eigentlich vor? Master oder Slave? Das, was du da machst, sieht nach slave aus, da gibt es mittlerweile eine Einstellung COMMIT ON RETURN YES, die muss nach der Language Clause platziert werden, die sollte das eigentlich schon tun.

D*B

Habs jetzt auch mit einer Test-STP probiert. Folgender Code:

create procedure test_cc()
language sql
begin

declare exit handler for sqlexception rollback;

insert into test values(1,'');
/* Dies löst einen SQL0803 aus (Doppelter Schlüsselwert)*/
insert into test values(1,'');

commit;

end;

Den Aufruf hab ich über RunSQLScripts vom System i Navigator gemacht. JDBC-Settings: Cursor stability(*CS)

Theoretisch müsste dann ja das erste INSERT zurückgesetzt werden oder hab ich da einen Denkfehler? Es klappt nicht. Auch nicht wenn ich nach dem Aufruf der STP explizit ein rollback ausführe...

[Martin82]

Slave.

Welches Proggi würdest du dann für solche Test-Sachen empfehlen?

Habs jetzt mit COMMIT=*ALL probiert. Damit scheints zu klappen!

[BenderD]

... immer das Umfeld, worin es später eingebunden wird.

D*B

Slave.

Welches Proggi würdest du dann für solche Test-Sachen empfehlen?

Habs jetzt mit COMMIT=*ALL probiert. Damit scheints zu klappen!

[UFK]

Der OpsNav war zwar recht fehleranfällig(und ist es vermutlich immer noch), aber zum Testen eigentlich klasse. Ich hab viele Scripts geschrieben, um Stored Procedures und Functions erstmal damit zu testen, mit gutem Erfolg. Sowohl einige positive als auch (mehr) negative Tests.

Außerdem möchte ich der Aussage mit dem Commitment-Control auch widersprechen. Bei größeren Stored-Procedures habe ich doch auch ROLLBACK verwendet, um letztendlich scheiternde Transaktionen ohne Würgen wieder glatt zu stellen, und das Verhalten in jeder Hinsicht getestet. Natürlich setzt man dann entsprechende Returncodes, damit z.B. Java-Programme mitbekommen, daß die Verarbeitung gescheitert ist.

PS: Benutzt Du eigentlich ATOMIC ?

[Martin82]

Bin da ganz bei dir mit deiner Meinung!

Nein, benutze kein ATOMIC!

[BenderD]

... ich erkenne zwar nicht welcher Aussage du da widersprechen willst, bei commit in Procedures sind schon ein paar Dinge zu beachten:
- Commit/Rollback ist eine Eigenschaft einer Connection bzw. der Activationgroup und wenn eine Procedure innerhalb einer gesicherten Transaktion aufgerufen wird und dann ein Commit oder Rollback absetzt, dann hat das Nebeneffekte für die offene Transaktion.
- gegen den Oops Nerv spricht hier in aller erster Linie die mangelnde Dokumentiertheit und daraus resultierende fehlende Reproduzierbarkeit. Gerade Abläufe wie hier riechen förmlich danach (so kann es für ein CREATE PROCEDURE wichtig sein, ob bei der Erstellung Commit aktiv ist, oder nicht).

D*B

Der OpsNav war zwar recht fehleranfällig(und ist es vermutlich immer noch), aber zum Testen eigentlich klasse. Ich hab viele Scripts geschrieben, um Stored Procedures und Functions erstmal damit zu testen, mit gutem Erfolg. Sowohl einige positive als auch (mehr) negative Tests.

Außerdem möchte ich der Aussage mit dem Commitment-Control auch widersprechen. Bei größeren Stored-Procedures habe ich doch auch ROLLBACK verwendet, um letztendlich scheiternde Transaktionen ohne Würgen wieder glatt zu stellen, und das Verhalten in jeder Hinsicht getestet. Natürlich setzt man dann entsprechende Returncodes, damit z.B. Java-Programme mitbekommen, daß die Verarbeitung gescheitert ist.

PS: Benutzt Du eigentlich ATOMIC ?