Id Sicherheit vor commit bei einer Transaktion

[Tom]

Hello,

Wenn man also keine "academic locks" benutzt ...

Habe ich noch nicht gehört, ich vermute mal du beziehst dich hier auf die Logik im Programm? Am besten noch einen Timestamp abspeichern und dann nach 1 - 2 Tagen die Daten abgrasen/filtern. Gehört für mich in den Workflow.

Das ist eigentlich nur ein Spitzname für eine Sperre "ct", die also mit langer Verzögerung wirkt. Und es ist auch nur dann eine wirkliche Sperre, wenn die Datenbank das Verfahren unterstützt. Das konnten bereits frühe Versionen von bTrieve... MySQL unterstützt es allerdings nicht, da muss man sich das selber basteln, am besten mit Triggers oder strored Procedures.

Es bezieht sich auf datenverändernde Aktionen, also in der Hauptsache UPDATE; DELETE gehört  auch dazu.

Bevor man einen Datensatz ändern darf, muss man ihn sich geholt haben und zusammen mit den Daten den "Conflict-Counter" (so hieß das bei bTrieve) auslesen.

Beim Zurückschreiben wird geprüft, ob der Zähler noch identisch ist und er wird dann erhöht. Wenn nein, wird das Schreiben eben abgelehnt. Bei MySQL realisiere ich das i. d. R. so, dass ich aus dem Zähler einen MD5-Hash bilde und an den Client (oder besser in dessen Session) mit ausliefere. Das verhindert Manipulation. Dass ein Hash doppelt auftritt uind so zum Zähler passt, sollte relativ unwahrscheinlich sein.

Aber wie schon erwähnt, das ist nur eine Absicherung für zustandslose Protokolle, also eben fürs Web.

Wenn es hier, aus welchem Grunde auch immer, um echte Transaktionen ging, dann vergiss meine Rede wieder.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg