Hello,
So ein "Konfliktcounter" existiert in MySQL in Form des TIMESTAMPs schon. Das vorderste TIMESTAMP-Feld wird bei Updates ja automatisch auf die aktuelle Zeit gesetzt. Wenn man sich also den gespeicherten Timestamp zum Zeitpunkt des Datensatzlesens merkt und beim Schreibversuch prüft, ob der Datensatz noch immer den gleichen Timestamp hat (am simpelsten, indem man das Timestamp-Feld inkl. der erforderlichen alten Zeit mit in die WHERE-Bedingung reinsetzt und dann die "affected rows" abfragt), dann wurde der Datensatz in der Zwischenzeit nicht verändert.
Andernfalls muß man sich was überlegen. :)
Oder hätte dein conflictcounter noch weitere Aufgaben?
Der Conflict-Counter zählt nur die Updates bzw. die schreibenden Zugriffe.
Da MySQL verflixt schnell ist, ist ein Timestamp in Sekunden-Quantelung nicht ausreichend.
Queries werden in weniger als 0.08 sec ausgeführt.
Man muss daher tatsächlich beides führen, wenn man Sicherheit und Information (wann wurde verändert) haben will.
Das gilt natürlich nur dann, wenn zwischen Lesen und Schreiben nicht mehr Zeit vergeht, als eine Sekunde. Da man aber Funktionen für den Datenbankzugriff i.d.R. so schreibt, dass sie auch für die automatisierte Vorgangsbearbeitung geeignet sind, sollte man das berücksichtigen. Dann funktioniert das nämlich nachher im Dialogbetrieb genausogut wie im Batch-Betrieb.
Interessant ist allerdings noch die Frage, wie man auf diesen Fehler (wenn er denn auftritt) reagiert.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau