Sperrung von Datensätzen

[Frank H]

Hallo,

ich habe eine kleine Datenbank-Anwendung geschrieben, die auf meinem PC gut funktioniert.
Auch kann ich das gleichzeitige Einfügen eines Datensatzes von zwei verschiedenen Benutzern simulieren und beobachten, dass der Wert des Primärschlüssels (AutoIncrement-Feld) beim Zurückschreiben in die Datenbank automatisch angepasst wird.

Allerdings mache ich mir noch Gedanken darüber, ob bei einer Client/Server Datenbank-Anwendung einzelne Datensätze gesperrt werden müssen, wenn mehrere Benutzer gleichzeitig auf den selben Datensatz zugreifen.

Da unter ADO.NET das DataSet nicht in Verbindung mit der Datenbank steht, können jedoch keine einzelnen Datensätze gesperrt werden.

In der Microsoft-Dokumentation ist dazu nur zu lesen, dass bei manchen Anwendungsfällen das pessimistische Locking notwendig ist, und es wird auf ADO.NET 2 verwiesen (MSDN-Dokumentation zum ADO.NET-DataSet).

Meine Frage lautet daher:
Wie kann ich feststellen, ob das optimistische Locking-System von ADO.NET für meinen Anwendungsfall ausreicht?

Gruß
Frank

[Andreas Kosch]

Hallo,

das pessimistische Sperrverfahren über einen längeren Zeitraum ist bei einer SQL-Datenbank eher unüblich. Im Fall einer MS SQL Server-Datenbank die Mehrbenutzerfähigkeit wird am Einfachsten über eine zusätzliche Spalte vom Typ ROWVERSION (alias TIMESTAMP) nachrüstet, so dass der Microsoft SQL Server automatisch bei jeder Aktualisierung eines Datensatzes einen binären Zeitstempel aufdrückt:

CREATE TABLE MitRowversion
(
  id    INT           NOT NULL IDENTITY PRIMARY KEY,
  wert1 VARCHAR(9)    NOT NULL,
  wert2 VARCHAR(9)    NOT NULL,
  datum SMALLDATETIME NOT NULL,
  ts    ROWVERSION
)

Wird nun über den DataSet-Designer von Visual Studio der TableAdapter über den Assistenten zusammengebaut, berücksichtigt dieser automatisch die ROWVERSION-Spalte:

UPDATE [dbo].[MitRowversion] SET 
  [wert1] = @wert1, [wert2] = @wert2, [datum] = @datum 
WHERE (([id] = @Original_id) 
  AND ([ts] = @Original_ts));
SELECT id, wert1, wert2, datum, ts 
FROM MitRowversion WHERE (id = @id)

Wenn nun ein anderer Benutzer den gleichen Datensatz bereits früher geändert hat, meldet sich ADO.NET beim Update-Aufruf des "Nachzüglers" mit einer DBConcurrencyException zu Wort. Das Programm kann danach entscheiden, welche Reaktion notwendig ist:

• Plan A: Die eigene Änderungen in jedem Fall zurückschreiben (d.h. die Änderung des anderen Benutzers wird überschrieben).
• Plan B: Den aktuellen Zustand des Datensatzes in das eigene DataSet nachladen, so dass die Änderungen des Dritten sichtbar werden.

Die Mehrbenutzerfähigkeit ist also weniger eine technische Frage, sondern hängt mehr vom Regelwerk des Arbeitsablauf ab.