Zitat Zitat von BenderD Beitrag anzeigen
... da geht ja wieder einiges durcheinander:
- mit dem API bleibt der Designfehler, dass damit nicht zugleich eine eigene Sperre angefordert wird
- die Prüfung kann frei ergeben und der Job blockiert trotzdem 60 sec, weil ein anderer dazwischen gerutscht ist
- Datenbanken setzen immer physische Sperren für updates
- das zugrunde liegende Problem, dass der Benutzerprozess Sperren hält und die Kontrolle bekommt bleibt bestehen - dieser Anfängerfehler gehört behoben, gerade wenn man die "Altanwendung" weiter braucht und benutzt.

D*B
Danke für die Antwort.
Die (minimale) Unsicherheit, dass jemand dazwischenrutscht, ist mir bewusst. (Ich hatte vorher schon geschrieben, dass das in unserem Fall kein Problem ist). Auf jeden Fall werden wir mit der neue Prüfung per API deutlich besser, als wenn wir die User bei jeder Sperre in den 60-Sekunden Wartezustand laufen lassen.

Desweiteren hattest du ja bereits früher geschrieben, dass alle Sperren aufgehoben sein sollten, wenn die Kontrolle an den User zurückgeht. Das ist aber doch nur eine Meinung (nämlich deine). Ich finde nicht, dass das eine allgemeingültige Weisheit ist. Wenn ich den ganzen Forumsthread Revue passieren lasse, meine ich, dass die meisten der Meinung sind, dass sie physiche Sperren ablehnen und stattdessen logische Sperren setzen würden. Das funktioniert selbstverständlich, ist aber meiner Ansicht nach nicht der einzige Weg. Ich sehe immer noch kein Problem bei physischen Sperren. Ein Umbau auf ein vollständig transaktionsgesteuertes Verfahren mit Commitmentt Control kann ich mir bei uns im Hinblick auf die bestehende Anwendung nicht vorstellen.

Dieter