Optimistisches Sperren ist eine Strategie, bei der Sie einen Datensatz lesen, eine Versionsnummer notieren (andere Methoden dazu umfassen Datumsangaben, Zeitstempel oder Prüfsummen/Hashes) und prüfen, ob sich die Version nicht geändert hat, bevor Sie den Datensatz zurückschreiben. Wenn Sie den Datensatz zurückschreiben, filtern Sie das Update nach der Version, um sicherzustellen, dass es atomar ist. (d. h. zwischen dem Überprüfen der Version und dem Schreiben des Datensatzes auf die Festplatte nicht aktualisiert wurde) und aktualisieren Sie die Version auf einen Schlag.
Wenn der Datensatz fehlerhaft ist (d. h. eine andere Version als Ihrer), brechen Sie die Transaktion ab und der Benutzer kann sie neu starten.
Diese Strategie eignet sich am besten für hochvolumige Systeme und dreistufige Architekturen, bei denen Sie für Ihre Sitzung nicht unbedingt eine Verbindung zur Datenbank aufrechterhalten. In dieser Situation kann der Client keine Datenbanksperren aufrechterhalten, da die Verbindungen aus einem Pool genommen werden und Sie möglicherweise nicht dieselbe Verbindung von einem Zugriff zum nächsten verwenden.
Pessimistisches Sperren ist, wenn Sie den Datensatz für Ihre ausschließliche Verwendung sperren, bis Sie damit fertig sind. Es hat eine viel bessere Integrität als optimistisches Sperren, erfordert jedoch, dass Sie mit Ihrem Anwendungsdesign vorsichtig sind, um Deadlocks zu vermeiden. Um pessimistisches Sperren zu verwenden, benötigen Sie entweder eine direkte Verbindung zur Datenbank (wie dies normalerweise in einer zweischichtigen Client-Server-Anwendung der Fall wäre) oder eine extern verfügbare Transaktions-ID, die unabhängig von der Verbindung verwendet werden kann.
Im letzteren Fall öffnen Sie die Transaktion mit der TxID und verbinden sich dann mit dieser ID erneut. Das DBMS verwaltet die Sperren und ermöglicht es Ihnen, die Sitzung über die TxID wieder aufzunehmen. So funktionieren verteilte Transaktionen, die zweiphasige Commit-Protokolle (wie XA- oder COM+-Transaktionen) verwenden.
