(0) exportieren Drucken
Alle erweitern

Grundlegendes zur Parallelitätssteuerung

Als Parallelitätssteuerung werden unterschiedliche Verfahren beschrieben, mit denen die Integrität der Datenbank erhalten wird, wenn mehrere Benutzer gleichzeitig Zeilen aktualisieren. Falsche Parallelität kann zu Problemen führen, beispielsweise Dirty Reads, Phantomlesezugriffe und nicht wiederholbare Lesevorgänge. Microsoft SQL Server JDBC Driver stellt Schnittstellen für alle von SQL Server verwendeten Parallelitätsverfahren bereit, um diese Probleme zu beheben.

HinweisHinweis:

Weitere Informationen zur SQL Server-Parallelität finden Sie unter "Verwalten des parallelen Datenzugriffs" in der SQL Server-Onlinedokumentation.

Der JDBC-Treiber unterstützt die folgenden Parallelitätstypen:

Parallelitätstyp Merkmale Zeilensperren Beschreibung

CONCUR_READ_ONLY

Read Only

Nein

Aktualisierungen über den Cursor sind nicht zulässig; es werden keine Sperren für die Zeilen aufrechterhalten, aus denen das Resultset besteht.

CONCUR_UPDATABLE

Optimistic Read Write

Nein

Die Datenbank geht davon aus, dass Zeilenkonflikte unwahrscheinlich, aber möglich sind. Zeilenintegrität wird mit einem Timestampvergleich geprüft.

CONCUR_SS_SCROLL_LOCKS

Pessimistic Read Write

Ja

Die Datenbank geht davon aus, dass Zeilenkonflikte wahrscheinlich sind. Zeilenintegrität wird mit Zeilensperren sichergestellt.

CONCUR_SS_OPTIMISTIC_CC

Optimistic Read Write

Nein

Die Datenbank geht davon aus, dass Zeilenkonflikte unwahrscheinlich, aber möglich sind. Zeilenintegrität wird mit einem Timestampvergleich überprüft.

Bei SQL Server 2005 und SQL Server 2008 ändert der Server dies in CONCUR_SS_OPTIMISTIC_CCVAL, wenn die Tabelle keine Timestampspalte enthält.

Wenn in SQL Server 2000 die zugrunde liegende Tabelle eine timestamp-Spalte aufweist, wird OPTIMISTIC WITH ROW VERSIONING selbst dann verwendet, wenn OPTIMISTIC WITH VALUES angegeben wurde. Wenn OPTIMISTIC WITH ROW VERSIONING angegeben wurde und die Tabelle keine Timestamps aufweist, wird OPTIMISTIC WITH VALUES verwendet.

CONCUR_SS_OPTIMISTIC_CCVAL

Optimistic Read Write

Nein

Die Datenbank geht davon aus, dass Zeilenkonflikte unwahrscheinlich, aber möglich sind. Zeilenintegrität wird mit einem Zeilendatenvergleich geprüft.

Nicht aktualisierbare Resultsets

Ein aktualisierbares Resultset ist ein Resultset, in dem Zeilen eingefügt, aktualisiert und gelöscht werden können. In den folgenden Fällen kann SQL Server keinen aktualisierbaren Cursor erstellen. Die generierte Ausnahme lautet "Das Resultset kann nicht aktualisiert werden".

Ursache Beschreibung Lösung

Anweisung wurde nicht mit JDBC 2.0-Syntax erstellt

In JDBC 2.0 wurden neue Methoden eingeführt, um Anweisungen zu erstellen. Bei der Verwendung von JDBC 1.0-Syntax ist das Resultset standardmäßig schreibgeschützt.

Geben Sie den Resultsettyp und die Parallelität beim Erstellen der Anweisung an.

Anweisung wurde mit TYPE_SCROLL_INSENSITIVE erstellt

SQL Server erstellt einen statischen Snapshotcursor. Dieser ist von den zugrunde liegenden Tabellenzeilen getrennt, um den Cursor vor Zeilenaktualisierungen durch andere Benutzer zu schützen.

Verwenden Sie TYPE_SCROLL_SENSITIVE, TYPE_SS_SCROLL_KEYSET, TYPE_SS_SCROLL_DYNAMIC oder TYPE_FORWARD_ONLY mit CONCUR_UPDATABLE, um das Erstellen eines statischen Cursors zu vermeiden.

Tabellenentwurf schließt einen KEYSET-Cursor oder einen DYNAMIC-Cursor aus

Die zugrunde liegende Tabelle weist keine eindeutigen Schlüssel auf, mit denen SQL Server eine Zeile eindeutig identifizieren kann.

Fügen Sie der Tabelle eindeutige Schlüssel hinzu, um eine eindeutige Identifikation jeder Zeile bereitzustellen.

Siehe auch

Anzeigen:
© 2014 Microsoft