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