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.
Hinweis
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. |