WITH LOCK
Blocage pessimiste.
DSQL, PSQL
SELECT ... FROM single_table [WHERE ...] [FOR UPDATE [OF <column-names>]] WITH LOCK [SKIP LOCKED]
L’option `WITH LOCK', fournit une option de verrouillage pessimiste explicite limitée pour une utilisation prudente dans les jeux de chaînes affectés :
-
un échantillon extrêmement réduit (idéalement une ligne) et
-
lors du contrôle à partir de l’application.
Caution
|
Pour les experts uniquement
Le verrouillage pessimiste est rarement nécessaire lorsqu’on travaille avec Firebird. Cette fonctionnalité ne peut être utilisée qu’avec une bonne compréhension de celle-ci. Une bonne connaissance des différents niveaux d’isolation et des autres paramètres de transaction est nécessaire avant d’utiliser le verrouillage explicite dans votre application. |
Si la clause WITH LOCK
réussit, elle verrouillera les lignes de données sélectionnées et les empêchera ainsi d’être modifiées dans d’autres transactions jusqu’à ce que votre transaction soit terminée.
La clause WITH LOCK
n’est disponible que pour sélectionner des données (SELECT
) dans une seule table.
La clause WITH LOCK
ne peut pas être utilisée :
-
dans les sous-requêtes ;
-
dans les requêtes avec jointure de plusieurs tables (
JOIN
) ; -
avec l’instruction
DISTINCT
, la clauseGROUP BY
et lors de l’utilisation de toute fonction d’agrégation ; -
lorsque vous travaillez avec des vues ;
-
lors de la sélection de données à partir de procédures stockées sélectives ;
-
lorsque vous travaillez avec des tables externes.
Le serveur, à son tour, pour chaque enregistrement soumis à un verrou explicite, renvoie la version de l’enregistrement qui est actuellement validée (à jour), quel que soit l’état de la base de données au moment de l’exécution de l’instruction d’extraction de données, ou une exception lors de la tentative de mettre à jour un enregistrement verrouillé.
Le comportement attendu et les messages de conflit dépendent des paramètres de transaction définis dans le TPB (Transaction Parameters Block) :
Effet des paramètres TPB sur le verrouillage explicite
Mode TPB | Comportement |
---|---|
isc_tpb_consistency |
Les verrous explicites sont remplacés par des verrous implicites ou explicites au niveau de la table et sont ignorés. |
isc_tpb_concurrency + isc_tpb_nowait |
Lorsqu’une modification d’enregistrement est confirmée dans une transaction qui a commencé après la transaction qui a déclenché le verrouillage explicite, une exception de conflit de mise à jour se produit immédiatement. |
isc_tpb_concurrency + isc_tpb_wait |
Lors de la confirmation d’un changement d’enregistrement dans une transaction qui a commencé après la transaction qui a lancé le lockout explicite, une exception de conflit de mise à jour se produit immédiatement. Si un changement de version d’enregistrement est en cours dans la transaction active (en utilisant le lockout explicite ou le lockout d’enregistrement optimiste normal), la transaction qui tente le lockout explicite attend jusqu’à ce que la transaction de lockout se termine et, lorsqu’elle se termine, essaie de faire en sorte que l’enregistrement soit de nouveau verrouillé. |
isc_tpb_read_committed + isc_tpb_nowait |
Si une transaction active modifie un enregistrement (en utilisant le verrouillage explicite ou le verrouillage optimiste normal des enregistrements), il y a une exception de conflit de mise à jour immédiate. |
isc_tpb_read_committed + isc_tpb_wait |
Si un enregistrement est en cours de modification dans une transaction active (à l’aide d’un verrouillage explicite ou d’un verrouillage optimiste normal des enregistrements), la transaction qui tente de procéder à un verrouillage explicite attend la fin de la transaction de verrouillage et, à ce moment-là, tente à nouveau de verrouiller l’enregistrement. Il n’y a jamais de conflit de mise à jour pour ce mode TPB. |