SetLockingMode

Question

Gibt es Empfehlungen, wann "optimistic" oder "pessimistic" verwendet werden soll?

Answer 1

Letztenendes kommt es auf die Workload an. Je höher die Konfliktrate, desto wahrscheinlicher, dass man mit "pessimistic", dem Standard, besser aufgehoben ist.

Je mehr man zu reinem Lesen tendiert, desto geringer die dann seltener auftretenden Konflikte und daher die Kosten für deren auflösung, wenn man "optimistisch" arbeitet.

Häufog betrachtet man hierbei auch einzelne Prozesse innerhalb der Datenbankapplikation, anstelle zu versuchen, die gesamte Datenbank gleichzubehandeln.

Zwei Links zum Weiterlesen:

Types of Concurrency Control

Concurrency Series: Basics of Transaction Isolation Levels

ich hoffe, das hilft weiter. Ansonsten gern die Frage noch konkretisieren.

Gruß,

Andreas

---

Andreas Wolter (Blog | Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com | www.SarpedonQualityLab.com

Answer 2

Ich habe eben nochmal nachgesehen. Der Titel "SetLockingMode" scheint mir einen C++ Hintergrund zu haben.

Dazu finde ich (CRecordset::SetLockingMode):

void SetLockingMode(
   UINT nMode 
);

nMode

    Enthält einen der folgenden Werte aus enum LockMode:

        optimistische Sperre optimistic sperrt den Datensatz, der nur während des Aufrufs zu Update aktualisiert wird.

        pessimistic vollständig Sperren wird der Datensatz, sobald Bearbeiten aufgerufen wird und hält sie gesperrt, bis der Update Aufruf abgeschlossen wird, oder Sie zu einem neuen Datensatz wechseln.

SQL Server unterscheidet zwischen Transaction Isolation Leveln

Das ist also noch eine Ebene granularar als rein "optimistic/pessimistic"

Dazu kommt, dass die C++ Klasse so oder so mit Sperren arbeitet, und lediglich die Dauer der Sperre variiert - es geht hier um die schreibende Transaktion. Zumindest lese ich das so (s.o.)
Wichtig ist ja auch, wie die Lesende Transaktion mit diesen Sperren umgeht.

Da ich über keine C++ Kenntnisse verfüge, würde ich abwarten ob sich dort noch jemand hier auskennt, oder in ein C++ Forum gehen.

Ich kann nur die SQL Server-Seite erläutern.

---

Andreas Wolter (Blog | Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com | www.SarpedonQualityLab.com

Answer 3

Man sollte in dem Zusammenhang auch mal über die Möglichkeiten der Zeilenversionsverwaltung nachdenken.
http://www.insidesql.org/blogs/cmu/sql_server/zeilenversionsverwaltung-row-level-versioning

Damit kann man einige Sachen entschärfen.

Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

Answer 4

Hallo zusammen,

wenn es sich wirklich um MFC und deren CRecordset handeln sollte, so basiert diese auf der Microsoft Access DAO Technologie.

Die wiederum unterstützt für ODBC Datenquellen - anders kann sie einen SQL Server Server nicht ansprechen -, nur optimistische Parallelität -  ODBCDirect (RDO für Arme) konnte etwas mehr, ist aber lange abgeschafft. Pessimistische Sperren sind bei DAO nur bei nativen (Jet-) Datenbanken möglich - und auch dort vermeidet man sie im allgemeinen. Pessimistische Sperren, wie die Jet unterstützt der SQL Server nur in Verbindung mit Cursorn (SCROLL LOCKS)[1].

Auf pessimistische Sperren sollte man in der Kombination verzichten, da sie die Parallelität massiv behindern. Die von Christoph angesprochene Zeilen-Versionierung unterstützt DAO nicht (der Stand ist dort in etwa SQL Server 2000 - 15 Jahre alt).  Die aktuellen Technologien wie ADO.NET verwenden ausschließlich optimistische Parallelität.

Zusammenfassung:
Anwendungen, die mehr als für eine oder zwei Handvoll Benutzer ausgelegt sein sollen, werden mit pessimistischer Parallelität (und nicht nur mit einem SQL Server) nicht funktionieren.

Gruß Elmar

[1] und das aus Tradition zu SQL Server 6.x, wo man mit DBase / ISAM konkurrieren wollte ;))

Answer 5

Die wiederum unterstützt für ODBC Datenquellen - anders kann sie einen SQL Server Server nicht ansprechen -, nur optimistische Parallelität -  ODBCDirect (RDO für Arme) konnte etwas mehr, ist aber lange abgeschafft. Pessimistische Sperren sind bei DAO nur bei nativen (Jet-) Datenbanken möglich - und auch dort vermeidet man sie im allgemeinen. Pessimistische Sperren, wie die Jet unterstützt der SQL Server nur in Verbindung mit Cursorn (SCROLL LOCKS)[1].

Auf pessimistische Sperren sollte man in der Kombination verzichten, da sie die Parallelität massiv behindern. Die von Christoph angesprochene Zeilen-Versionierung unterstützt DAO nicht (der Stand ist dort in etwa SQL Server 2000 - 15 Jahre alt).  Die aktuellen Technologien wie ADO.NET verwenden ausschließlich optimistische Parallelität.

...

Hallo Elmar,

bist Du sicher, dass es die pessimistische concurrency control ist, die mithilfe von Cursors implementiert wird?

Ich war mal neugierig und habe dazu nur das gefunden:

Optimistic and Pessimistic Concurrency (SQL 2000):

"Microsoft® SQL Server™ 2000 offers both optimistic and pessimistic concurrency control. Optimistic concurrency control uses cursors. Pessimistic concurrency control is the default for SQL Server.

Es mag natürlich sein, dass der Hintergrund hier ein anderer ist, aber wundern tut es mich schon leicht, daher nur um sicherzustellen, das nichts vertauscht wurde..

Gruß,

Andreas

---

Andreas Wolter (Blog | Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com | www.SarpedonQualityLab.com

Answer 6

Hallo Andreas,

die Frage gilt aus Sicht des Client API - nicht zu verwechseln, wie serverseitig Sperren in der relationalen Engine eingesetzt werden.

In SQL wäre eine pessimistische Sperre nur durch eine SELECT Anweisung mit UPDLOCK erreichbar. Was aber bedeuten würde, dass man die Zeile lesen müsste und eine Transaktion über die gesamte Laufzeit offen halten. Dies würde aber bedeuten Zeile für Zeile zu verarbeiten. Liest man oben weiter bei den, Cursorn so findet man:
SCROLL LOCKS

This option implements pessimistic concurrency control, in which the application attempts to lock the underlying database rows at the time they are read into the cursor result set. When using server cursors, an update lock is placed on the row when it is read into the cursor.

Das gilt auch für spätere Versionen, nur da schreibt man es nicht mehr so deutlich, wie z. B. in der BOL zur SQL Server 2008 R2.

Das ist in SQL für eine Abfrage nicht möglich. Ein UPDLOCK über eine gesamte Abfrage (und der erforderlichen Transaktion) wäre etwas anderes - und nebenbei absolut tödlich ;)

Der Client muss dazu einen sog. serverseitigen Cursor verwenden und entsprechende Einstellungen. Und man findet sie beim Profiling als sp_cursor Aufrufe[1].

Das Konzept hat man in ADO / Ole Db um die sog. clientseitigen Cursor ergänzt. Das wurde - so um 1999 - das bevorzugte API. Dabei werden die Daten lokal eingelesen und Aktualisierungen erfolgen optimistisch. ADO.NET kennt nur noch dieses Modell.

MFC DAO existiert nur aus Kompatibilität zu alten Anwendungen (MFC ist nun mal nicht tot zu kriegen ;) OleDb ist für den Client bereits abgekündigt, siehe Data Access Technologies Road Map.[2]

Summa Summarum: Selbst wenn man pessimistisch sperren wollte, könnte man es mit "aktuellen" Technologien nicht mehr.

Gruß Elmar

[1] Fußnote am Rande: Damals man sie noch brauchte, waren sie nicht mal anständig (offiziell) dokumentiert (zum Vergleich SQL Server 2000: API Server Cursors).

[2] Wenn man noch mehr in Erinnerungen schwelgen möchte: Microsoft Data Development Technologies: Past, Present, and Future.

Answer 7

Hallo

vielen Dank Elmar, für Deine ausführlichen Erläuterungen :)

"Cursor" ist also das Stichwort, unter dem sich all das findet.

---

Andreas Wolter (Blog | Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com | www.SarpedonQualityLab.com