begin transaction, commit und rollback

kellerassel schrieb:

macht nichts, hab mich schon daran gewöhnt, es mir aus den fingern zu saugen

Es gibt da eine tolle Erfindung: Das Fachbuch. Da brauchste Dir gar nichts aus den Fingern zu saugen, man kann das alles nachlesen. Alternativ gibt es auch diverse Informationsquellen im Internet wo man solche trivialen Sachen jederzeit seit fast 30 Jahren nachlesen kann.

Man darf halt nicht zu faul zum suchen sein.

rüdiger

https://en.wikipedia.org/wiki/Database_transaction

C++ Forumbot

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Datenbanken verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

okay ich versuch mal, wo es hapert...

start transaction;
update ....
select ...
if not found_rows() then
  rollback;
else
  commit;
end if;

das wär schon mal okay, oder?

start transaction;
update ....
select ...
if not found_rows() then
  rollback;
end if;

update ....
select ...
if not found_rows() then
  rollback;
end if;

commit;

das ist auch okay, oder?

wenn jetzt das zweite beispiel darauf vertraut, dass zwischen den zwei updates in der tabelle nichts ändert, brauch ich dann ein lock tables?

und was passiert in dem 2. bsp. mit dem result set aus dem ersten und zweiten select, wenn der letzte rollback zurückrollt? wird das an den client geschickt

ist sowas gültiges sql?

start transaction;
rollback;
commit;

das wären meine fragen

start transaction;
update ....
select ...
if not found_rows() then
  rollback;
  leave ...;
end if;

update ....
select ...
if not found_rows() then
  rollback;
  leave ...;
end if;

commit;

ups... hier müsste natürlich ein leave rein verzwickte geschichte

hustbaer

kellerassel schrieb:

okay ich versuch mal, wo es hapert...
start transaction;
update ....
select ...
if not found_rows() then
  rollback;
else
  commit;
end if;
das wär schon mal okay, oder?

ja

start transaction;
update ....
select ...
if not found_rows() then
  rollback;
end if;

update ....
select ...
if not found_rows() then
  rollback;
end if;

commit;

das ist auch okay, oder?

bis auf das fehlende leave, ja

wenn jetzt das zweite beispiel darauf vertraut, dass zwischen den zwei updates in der tabelle nichts ändert, brauch ich dann ein lock tables?

stichwort: transaction isolation
http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html
bei "repeatable read" bzw. "serializable" brauchst du nichts weiter.

und was passiert in dem 2. bsp. mit dem result set aus dem ersten und zweiten select, wenn der letzte rollback zurückrollt? wird das an den client geschickt

normalerweise ja. probier es halt aus.
EDIT: die result-sets werden üblicherweise sofort an den client geschicht, d.h. beim rollback ist es schon zu spät. /EDIT

ist sowas gültiges sql?
start transaction;
rollback;
commit;

rollback beendet normalerweise die transaktion, d.h. das folgende commit ist ein fehler (gibt nix zu committen).

danke für die antworten!

hustbaer schrieb:

wenn jetzt das zweite beispiel darauf vertraut, dass zwischen den zwei updates in der tabelle nichts ändert, brauch ich dann ein lock tables?

stichwort: transaction isolation
http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html
bei "repeatable read" bzw. "serializable" brauchst du nichts weiter.

okay, um auf nummer sicher zu gehen ein konkeretes beispiel: z.b. will ich einem kindknoten einen anderen kindknoten anhängen:

start transaction;
declare _parent_id int;
select parent_id from tree where id = 2 into _parent_id;
insert into tree(parent_id,...) values (_parent_id,...);
commit;

da kann jetzt keiner zwischen select und insert daher kommen, und den knoten mit der _parent_id löschen, oder

btw. der link bezieht sich eher auf innodb. gilt aber auch für ndb, wenn ich später mal umsteigen sollte

declare _parent_id int;

start transaction;
select parent_id from tree where id = 2 into _parent_id;
insert into tree(parent_id,...) values (_parent_id,...);
commit;

so ist es besser

kellerassel schrieb:

declare _parent_id int;

bei auto_incremet 'int unsigned' aber das ist ja jetzt nicht so wichtig, oder

hustbaer

kellerassel schrieb:

okay, um auf nummer sicher zu gehen ein konkeretes beispiel: z.b. will ich einem kindknoten einen anderen kindknoten anhängen:
start transaction;
declare _parent_id int;
select parent_id from tree where id = 2 into _parent_id;
insert into tree(parent_id,...) values (_parent_id,...);
commit;
da kann jetzt keiner zwischen select und insert daher kommen, und den knoten mit der _parent_id löschen, oder

"repeatable read" sollte hier mMn. ausreichend sein. Bei "repeatable read" muss das SELECT nen "read lock" holen, und der würde mit einem DELETE/UPDATE auf die selbe Zeile kollidieren (d.h. eine der beiden Transaktionen wird verzögert bis die andere committed - wobei es natürlich u.U. zu Deadlocks kommen kann).

Ein passender "Referential Integrity Constraint" sollte aber auch reichen um in diesem Fall Probleme zu vermeiden (ganz ohne Transaktion). Wenn es den gibt, dann schlägt das INSERT im Falle des Falles einfach fehl, weil keine Zeilen eingefügt werden deren "parent_id" Feld auf eine nicht-existierende Zeile verweist.
(Bzw. Zeilen auch nur dann gelöscht werden können, wenn sie nicht mehr von anderen Zeilen referenziert werden)

btw. der link bezieht sich eher auf innodb. gilt aber auch für ndb, wenn ich später mal umsteigen sollte

Keine Ahnung, musst du halt gucken (ich kenn mich mit MySQL nicht wirklich aus, ich verwende persönlich nur MSSQL).