@jobo: Meine Antwort war nicht als Kritik an Deinem Vorschlag gemeint. Dein Vorschlag ist ok und so umsetztbar und absolut sinnvoll. Wollte damit nur sagen, dass gegen Deinen Vorschlag nichts, aber auch garnichts einzuwenden ist
Ok. Muss wohl an meinen Formulierungen feilen
@hoika:
Natürlich ist ein Execute-Block keine Transaktion, man sollte selbstverständlich vor dem Aufruf des Blockes eine Transaktion starten und beim Beenden mit Commit schließen. Im Fehlerfalle macht man ein Rollback.
..
Zunächst, ich habe es nicht als Kritik aufgefasst, vielleicht muss ich auch die Feile rausholen...
Zum Thema Transaktion:
Aus Sicht der Datenbank ist alles eine Transaktion, die ist nämlich per Definition dafür verantwortlich, dass nichts anbrennt. Und dabei ist es ihr auch sch.. egal, was der Client macht. Es muss ihr egal sein, die
DB ist der Server und der Client der Client.
Wenn ich also ein einzelnes Updatestatement absetze oder einen anonymen Block laufen lasse (der meinetwegen 5 Minuten für ganz viele Updates und Inserts braucht), beides ist jeweils eine Transaktion und funktioniert entweder oder es funktioniert nicht. Demzufolge ist unabhängig von meiner Clientprogrammierung die Sache am Ende erledigt oder es steht wieder alles auf Anfang.
Ich brauche demzufolge keine Clienttransaktion, sondern eher ein Errorhandling um die Anwenderkommunikation und Programmdarstellung gerade zu ziehen.
Ein anonymer Block wie im Beispiel, mit 2 Statements, die zusammen wahrscheinlich weniger als 0.5 Sekunden brauchen(-je nach Indizierung und update Kriterien), ist die beste Möglichkeit, Ressourcen zu schonen, Dead Locks zu vermeiden und einfach schnell zu sein. Ursache und Wirkung sind dabei austauschbar, denn es ist naheliegend, dass viele User, deren Statements sich verkürzen, sich gegenseitig weniger im Weg stehen mit ihren Transaktionen.
Ich würde noch weiter gehen und sagen, explizite Transaktionskontrolle im Client ist böse, aber dafür kann man bei Interesse ein neuen thread aufmachen.