Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Das hatte ich vermutet.

Was hälst du von einem Lock auf die entsprechende Tabelle während des Lesevorgangs und des Kennzeichnens für "in Bearbeitung"?? der eigentliche Job kann auch danach ausgeführt werden.

Nichts. Wir reden doch über HTTP, oder? Da funktioniert das nicht!
Ein Vorgang erstreckt sich i.d.R. über mehrere Roundtourns, ein physisches Lock gilt aber nur für einen davon.

Ein DBMS kümmert sich um kurze Locks selber, je nach Maschine darunter auf Tabellenebene (MyISAM) oder auf Satzebene (innoDB). Die beiden Maschinen hier nur als Beispiele.

Es gibt zwei Strategien:

• "Happy Forward" oder optimistic Locking
    gesperrt wird erst zur tatsächlichen Veränderung
    dabei wird gesperrt, der alte Satz nochmal gelesen, mit dem im alten Blockbuffer verglichen,
    und bei Gleichkeit der alten Buffer wird der neue geschrieben.

Bei Ungleichheit hat der Bearbeiter die Arschkarte. Seine Arbeit war für die Katz

Alternativ zu den Blockbuffern kann man auch einen Clonflict-Counter (Schreibzähler) führen.
  Den sollte man dann durch einen Trigger überwachen lassen. Nur bei Gleichheit zwischen Lesen
  und Schreiben wird geschrieben und der Zähler gleichzeitig eins hochgezählt

• "Scaredy cat" oder pessimistic Locking
    Der Datensatz wird vor dem _Bearbeiten_ im Offline-Buffer für den Bearbeiter gesperrt.
    Das geht ganz einfach, indem man ein

"Update table set bearbeiter = id_bearbeiter where id = $satzid and id_bearbeiter = 0"

absetzt, kontrolliert, ob das Statement genau einen Satz verändert hat. Ab dann hat man Ruhe.
  Außerdem kann jeder andere Bearbeiter die Information abrufen, wer gerade auf den Daten
  sitzt.

Dieses Verfahren verhindert i.d.R. eher deadlocks, als das andere, verlangsamt aber auch
  meistens die Verwaltungsabläufe

Leider können auf diese Weise Lost Locks entstehen, da bei HTTP ja nicht klar ist, ob der Bearbeiter jemals wiederkommt. Im Web sollte man derartige Sperren daher mindestens noch mit einem Timeout versehen.

Und da sind wir auch schon beim nächsten Konzeptschritt:
Die Verwaltungsinformationen werden nicht mehr direkt in der zu verändernden Tabelle vermerkt, sondern in einer separaten Tabelle, die dann aber bei allen Veränderungen in die Statements mit einbezogen werden muss.

Diese kann man dann beim Logout bereinigen bzw. von Zeit zu Zeit auf abgelaufene Sperren untersuchen. Außerdem kann man nach Belieben Spalten hinzufügen, ohne die eigentlichen Datentabellen damit behelligen zu müssen.

Spirituelle Grüße
Euer Robert