Grundlegendes zur Parallelitätssteuerung

  • Artikel

JDBC-Treiber herunterladen

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 JDBC-Treiber für SQL Server stellt Schnittstellen für alle von SQL Server verwendeten Parallelitätsverfahren bereit, um diese Probleme zu beheben.

Hinweis

Weitere Informationen zu Parallelität in SQL Server finden Sie unter Verwalten des parallelen Datenzugriffs.

Bemerkungen

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

Parallelitätstyp Merkmale Anzahl von Zeilensperren BESCHREIBUNG
CONCUR_READ_ONLY Nur Leseberechtigung Nein Updates ü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 (9.x) und höher ändert der Server dies in CONCUR_SS_OPTIMISTIC_CCVAL, wenn die Tabelle keine timestamp-Spalte enthält.

Wenn in SQL Server 2000 (8.x) 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 Problembehandlung
Anweisung wurde nicht mit JDBC 2.0-Syntax (oder neuer) 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 Momentaufnahmencursor. Dieser ist von den zugrunde liegenden Tabellenzeilen getrennt, um den Cursor vor Zeilenudpates 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.

Weitere Informationen:

Verwalten von Resultsets mit dem JDBC-Treiber