Hallo dedlfix, das ist richtig, aber bei der Verarbeitung des Submit habe ich es in der Hand, über entsprechende DB-Locks (sprich: Transaktion und Isolation Level) die anderen auszusperren. Damit tausche ich dann zwar ggf. den TOCTTOU gegen einen DEADLOCK ein, aber letzteren sollte man mittels passender Update-Reihenfolge lösen können. Wenn man alle Update-Prozesse selbst in der Hand hat, gibt es auch die Möglichkeit, über einen Semaphor logische Locks zu erschaffen, die keine DB-Locks sind (sprich: eine DB-Tabelle, in der für ein "Thema" ein Besitzer gesetzt wird, dann werden alle Updates für das Thema gemacht und zum Abschluss das Thema wieder freigegeben. Die Themen müssen natürlich so gewählt werden, dass sich die Updates zweier Themen nicht überschneiden können. Wenn doch, muss für die Schnittmenge ein eigenes Thema definiert werden und der Updater muss sich mehrere Themen reservieren, bevor er loslegt. Setzen und Löschen des Themas sind kurzlaufende Aktionen und lassen sich mittels optimistischem Sperrverfahren ohne DB-Locks umsetzen (Mehrfachthemen natürlich nicht, dafür braucht's wieder eine Transaktion). Ist natürlich kritisch, wenn das Script beim Owner abbricht, weil dann der Semaphor gesetzt bleibt, da muss man entsprechende Exception-Fänger installieren und ggf. eine Logik einbauen, die einen "zu alten" Semaphor als "vergessen" betrachtet und überschreibt. _Rolf_ -- sumpsi - posui - clusi

Hallo dedlfix, das ist richtig, aber bei der Verarbeitung des Submit habe ich es in der Hand, über entsprechende DB-Locks (sprich: Transaktion und Isolation Level) die anderen auszusperren. Damit tausche ich dann zwar ggf. den TOCTTOU gegen einen DEADLOCK ein, aber letzteren sollte man mittels passender Update-Reihenfolge lösen können. _Rolf_ -- sumpsi - posui - clusi