Comprendre le contrôle de la concurrence

Télécharger le pilote JDBC

Le contrôle concurrentiel fait référence aux différentes techniques utilisées pour conserver l'intégrité de la base de données lorsque plusieurs utilisateurs mettent à jour des lignes en même temps. Une mauvaise gestion de la concurrence peut entraîner des problèmes tels que des lectures sales, des lectures fantômes et des lectures non répétables. Microsoft JDBC Driver for SQL Server fournit des interfaces pour toutes les techniques de concurrence utilisées par SQL Server afin de résoudre ces problèmes.

Note

Pour plus d’informations sur l’accès simultané SQL Server, consultez « Gestion de l’accès concurrentiel aux données ».

Remarques

Le pilote JDBC prend en charge les types d'accès simultanés suivants :

Type d'accès simultané Caractéristiques Verrouillage des lignes Description
CONCUR_READ_ONLY Lecture seule Non Les mises à jour via le curseur ne sont pas autorisées, et aucun verrou n'est appliqué sur les lignes qui composent le jeu de résultats.
CONCUR_UPDATABLE Lecture/écriture optimistes Non La base de données part du principe qu’une contention au niveau des lignes est peu probable, mais possible. L'intégrité de la ligne est vérifiée au moyen d'une comparaison des horodatages.
CONCUR_SS_SCROLL_LOCKS Lecture/écriture pessimistes Oui La base de données part du principe qu'une contention au niveau des lignes est probable. L’intégrité des lignes est garantie grâce au verrouillage des lignes.
CONCUR_SS_OPTIMISTIC_CC Lecture/écriture optimistes Non La base de données part du principe qu’une contention au niveau des lignes est peu probable, mais possible. L’intégrité de la ligne est vérifiée par comparaison des horodatages.

Pour SQL Server 2005 (9.x) et versions ultérieures, le serveur remplace ceci par CONCUR_SS_OPTIMISTIC_CCVAL, si la table ne contient pas de colonne timestamp.

Pour SQL Server 2000 (8.x), si la table sous-jacente a une colonne timestamp, OPTIMISTIC WITH ROW VERSIONING est utilisé même si OPTIMISTIC WITH VALUES est spécifié. Si OPTIMISTIC WITH ROW VERSIONING est spécifié et que la table ne possède pas d'horodateurs, OPTIMISTIC WITH VALUES est utilisé.
CONCUR_SS_OPTIMISTIC_CCVAL Lecture/écriture optimistes No La base de données part du principe que la contention entre lignes est peu probable, mais possible. L'intégrité des lignes est vérifiée au moyen d'une comparaison des données de ligne.

Jeux de résultats qui ne peuvent pas être mis à jour

Un jeu de résultats pouvant être mis à jour est un jeu de résultats dans lequel des lignes peuvent être insérées, mises à jour et supprimées. Dans les cas suivants, SQL Server ne peut pas créer de curseur pouvant être mis à jour. L'exception générée est « Le jeu de résultats n'est pas modifiable. »

Cause Description Correctif
L'instruction n'est pas créée à l'aide de la syntaxe JDBC 2.0 (ou ultérieure) JDBC 2.0 introduit de nouvelles méthodes pour créer des instructions. Si la syntaxe JDBC 1.0 est utilisée, le jeu de résultats est par défaut en lecture seule. Spécifiez le type de jeu de résultats et le mode de concurrence lors de la création de l'instruction SQL.
L'instruction est créée à l'aide de TYPE_SCROLL_INSENSITIVE SQL Server crée un curseur instantané statique. Il est déconnecté des lignes de la table sous-jacente afin de protéger le curseur contre les mises à jour des lignes effectuées par d'autres utilisateurs. Utilisez TYPE_SCROLL_SENSITIVE, TYPE_SS_SCROLL_KEYSET, TYPE_SS_SCROLL_DYNAMIC ou TYPE_FORWARD_ONLY avec CONCUR_UPDATABLE pour éviter de créer un curseur statique.
La conception de table ne permet pas un curseur KEYSET ou DYNAMIC La table sous-jacente n’a pas de clés uniques pour permettre à SQL Server d’identifier une ligne de manière unique. Ajoutez des clés uniques à la table afin de fournir une identification unique de chaque ligne.