Accès concurrentiel au curseur (moteur de base de données)
Microsoft SQL Server prend en charge quatre options d'accès concurrentiel pour les curseurs côté serveur :
READ_ONLY
OPTIMISTIC WITH VALUES
OPTIMISTIC WITH ROW VERSIONING
SCROLL LOCKS
READ_ONLY
Les mises à jour positionnées effectuées à l'aide du curseur ne sont pas autorisées et aucun verrou n'est maintenu sur les lignes constituant l'ensemble de résultats.OPTIMISTIC WITH VALUES
Le contrôle de l'accès concurrentiel optimiste est un élément standard de la théorie du contrôle des transactions. Cette option est utilisée dans des situations où il est peu probable qu'un autre utilisateur ou processus puisse mettre à jour une ligne entre le moment où un curseur a été ouvert et celui où la ligne a été mise à jour. Lorsqu'un curseur est ainsi ouvert, aucun verrou n'est maintenu sur les lignes sous-jacentes, ce qui contribue à optimiser le débit. Si l'utilisateur tente de modifier une ligne, les valeurs actuelles de celle-ci sont comparées aux valeurs récupérées lors de la dernière extraction de la ligne. Si une valeur a été modifiée, le serveur est informé qu'un autre utilisateur ou processus a déjà mis à jour la ligne, il retourne donc une erreur. Si les valeurs sont les mêmes, le serveur procède à la modification.La sélection de cette option d'accès concurrentiel contraint l'utilisateur ou le programmeur d'accepter la responsabilité de traiter les erreurs occasionnelles indiquant qu'un autre utilisateur a modifié la ligne. En général, une application recevant ce type d'erreur procède à l'actualisation du curseur, extrait les nouvelles valeurs, puis invite l'utilisateur à décider s'il doit appliquer la modification aux nouvelles valeurs. Les colonnes text, ntext et image ne sont pas utilisées pour les comparaisons d'accès concurrentiel des versions 6.5 ou antérieures de SQL Server.
OPTIMISTIC WITH ROW VERSIONING
Cette option de contrôle d'accès concurrentiel optimiste dépend du versioning de ligne. Avec le versioning de ligne, les tables sous-jacentes doivent avoir un identificateur de version d'un type donné que le serveur peut utiliser pour déterminer si la ligne a été modifiée après avoir été lue dans le curseur. Dans SQL Server, cette fonction est proposée par le type de données timestamp, nombre binaire indiquant la séquence relative de modifications effectuées dans une base de données. Chaque base de données comporte une valeur globale timestamp actuelle, **@@**DBTS. Chaque fois qu'une ligne avec une colonne timestamp est modifiée d'une façon ou d'une autre, SQL Server stocke la valeur **@@**DBTS actuelle dans la colonne timestamp, puis incrémente **@@**DBTS. Si une table contient une colonne timestamp, les cachets temporels apparaissent au niveau de la ligne. Le serveur peut ensuite comparer la valeur timestamp actuelle d'une ligne à la valeur timestamp qui était stockée au moment où la ligne a été extraite pour la dernière fois, afin de déterminer si elle a été modifiée. Le serveur n'a pas besoin de comparer les valeurs de toutes les colonnes, mais uniquement celles de la colonne timestamp. Si une application demande un contrôle d'accès concurrentiel optimiste avec versioning de ligne dans une table ne disposant pas de colonne timestamp, le curseur affiche par défaut les valeurs du contrôle d'accès concurrentiel optimiste.Notes
Pour les curseurs ouverts sur des sources de données distantes, les mises à jour par l'intermédiaire du curseur ne sont pas prises en charge si la source de données distante ne contient pas de colonne timestamp.
SCROLL LOCKS
Cette option implémente le contrôle d'accès concurrentiel pessimiste, au moyen duquel l'application tente de verrouiller les lignes sous-jacentes de la base de données au moment où elles sont lues dans l'ensemble de résultats du curseur. En cas d'utilisation de curseurs de serveur, un verrou de mise à jour est placé sur la ligne lorsque celle-ci est lue dans le curseur. Si le curseur a été ouvert au cours d'une transaction, le verrou de mise à jour de transaction est maintenu jusqu'à ce que la transaction soit validée ou restaurée ; le verrou est supprimé au moment de l'extraction de la ligne suivante. Si le curseur a été ouvert en dehors d'une transaction, le verrou est supprimé au moment de l'extraction de la ligne suivante. Par conséquent, un curseur doit être ouvert au cours d'une transaction chaque fois qu'un contrôle d'accès concurrentiel pessimiste est demandé. Le verrouillage de mise à jour empêche toute autre tâche d'obtenir un verrou de mise à jour ou un verrou exclusif, ce qui empêche la mise à jour de la ligne. Toutefois, un verrou de mise à jour ne bloque pas un verrou partagé. Il ne peut donc pas empêcher les autres tâches de lire la ligne, à moins que la seconde tâche demande également une lecture avec un verrou de mise à jour.
Verrous de défilement
Ces options d'accès concurrentiel au curseur peuvent générer des verrous de défilement, en fonction des indicateurs de verrouillage spécifiés dans l'instruction SELECT de la définition du curseur. Les verrous de défilement peuvent être obtenus sur chaque ligne pendant une extraction et être maintenus jusqu'à l'extraction suivante ou la fermeture du curseur, selon ce qui se produit en premier. Lors de l'extraction suivante, le serveur obtient des verrous de défilement pour les lignes de la nouvelle extraction, puis libère ceux des lignes de l'extraction précédente. Les verrous de défilement sont indépendants des verrous de transaction et leur action peut persister après une validation ou une restauration. Si l'option de fermeture des curseurs pendant la validation est désactivée, l'instruction COMMIT ne ferme aucun curseur ouvert et les verrous de défilement sont conservés après la validation afin de maintenir le niveau d'isolement des données extraites.
Le type des verrous de défilement obtenus dépend de l'option d'accès concurrentiel au curseur et des indicateurs de verrouillage spécifiés dans l'instruction SELECT de la définition du curseur.
Notes
Les verrous de défilement sont pris en charge uniquement pour les curseurs pilotés par jeux de clés et les curseurs dynamiques.
Indicateurs de verrouillage |
En lecture seule |
Optimiste avec valeurs |
Optimiste avec versioning de ligne |
Verrouillage |
|---|---|---|---|---|
Pas d'indicateur |
- |
- |
- |
Mise à jour |
NOLOCK* |
- |
- |
- |
- |
HOLDLOCK |
- |
- |
- |
Mise à jour |
UPDLOCK |
- |
- |
- |
Mise à jour |
TABLOCKX |
- |
- |
- |
Mise à jour |
Autres |
- |
- |
- |
Mise à jour |
*En spécifiant l'indicateur NOLOCK, la table sur laquelle est effectuée la spécification est en lecture seule via le curseur.
Spécification des options d'accès concurrentiel au curseur
Les options d'accès concurrentiel sont spécifiées de manière différente dans chaque environnement de curseur :
Curseurs Transact-SQL
Spécifiez les mots clés READ_ONLY, SCROLL_LOCK et OPTIMISTIC dans l'instruction DECLARE CURSOR. Le mot clé OPTIMISTIC spécifie le contrôle d'accès concurrentiel optimiste avec versioning de ligne. Les curseurs Transact-SQL ne prennent pas en charge l'option d'accès concurrentiel optimiste.
Applications ADO
Spécifiez adLockReadOnly, adLockPessimistic, adLockOptimistic ou adLockBatchOptimistic dans la propriété LockType d'un objet Recordset.
Applications ODBC
Affectez à l'attribut d'instruction SQL_ATTR_CONCURRENCY la valeur SQL_CONCUR_READ_ONLY, SQL_CONCUR_ROWVER, SQL_CONCUR_VALUES ou SQL_CONCUR_LOCK.