Diskussion:Zeitstempelverfahren

Ich denke, dass in der Beschreibung zwei verschiedene Synchronisierungsstrategien vermischt wurden und nicht jedes Zeitstempelverfahren "optimistisch" ist.

Das Verfahren, wie es ab "In praktischen Anwendungen..." beschrieben wird, ist in der Tat optimistisch, allerdings benötigen Objekte dafür keine Zeitstempel, lediglich die Transaktionen.

Bekommen auch die Objekte Zeitstempel und erfolgt eine Überprüfung bei Objektzugriff, so kann dieses Verfahren die Synchronisation mit Sperren ersetzen. Damit wäre das Verfahren aber (wie bei der Verwendung von Sperren) pessimistisch. (nicht signierter Beitrag von 87.174.239.175 (Diskussion) 15:02, 12. Sep. 2010 (CEST))

Kein optimistisches Verfahren

Zeitstempelbasierte Verfahren sind definitiv NICHT optimistisch, sondern pessimistisch, da im Allgemeinen mehr Transaktionen zurückgesetzt werden als zur Deadlockvermeidung zwingend nötig, was bei optimistischen Verfahren in der Regel nicht der Fall ist. (vgl. Kemper, Eickler: Datenbanksysteme, Eine Einführung p. 345) (nicht signierter Beitrag von 85.181.120.101 (Diskussion) 20:03, 2. Feb. 2013 (CET))

Ich kann mich meinen Vorrednern nur anschließen: Der Artikel vermischt Themen und enthält falsche Informationen --> korrigieren / löschen

Das Zeitstempelverfahren ist definitiv ein pessimistisches Synchronisationsverfahren: Eine Transaktion wird sofort abgebrochen, wenn ein Konflikt entstehen KÖNNTE: Eine Transaktion wird abgebrochen, wenn a) ein Datum gelesen werden soll, das von einer jüngeren Transaktion geschrieben wurde b) ein Datum geschrieben werden soll, das von einer jüngeren Transaktion gelesen oder geschrieben wurde

In diesem Zusammenhang sollte auch die "Thomas Write Rule" erwähnt werden, die Transaktionen im Fall b) nur abbricht, wenn das Datum von einer jüngeren Transaktion gelesen wurde.

Der Abschnitt "Grundlegende Validierungstechniken" beschreibt hingegen zwei optimistische Synchronisationsverfahren (BOCC & FOCC), deren Implementierung (read & write sets) mittels Zeitstempeln gelöst werden kann. [ http://www.inf.fu-berlin.de/lehre/SS05/19517-V/FolienEtc/dbs04-19-ConCtrl-1-6.pdf ]

Optimistische Verfahren führen die Transaktion zuerst auf Kopien aus und a) überprüfen erst beim commit, ob es zu einem Konflikt gekommen ist und brechen die Transaktion nachträglich ab (Backward oriented concurrency control (BOCC)) b) oder brechen beim commit noch laufende Transaktionen ab, die in Konflikt stehen (Forward oriented concurrency control (FOCC)) (nicht signierter Beitrag von 92.206.81.101 (Diskussion) 21:29, 25. Nov. 2013 (CET))