FirebirdSQL logo
 Variables de contexteSécurité 

Mode de résolution de verrouillage

Lorsque plusieurs applications clientes travaillent avec la même base de données, des verrous peuvent apparaître. Un verrou peut se produire lorsqu’une transaction apporte des modifications non approuvées à une ligne de la table ou supprime une ligne, et qu’une autre transaction tente de modifier ou de supprimer la même ligne. De tels verrous sont appelés conflits de mise à jour.

Les blocages peuvent également se produire dans d’autres situations lors de l’utilisation de certains niveaux d’isolation des transactions.

Il existe deux modes de résolution du verrouillage : WAIT et NO WAIT.

Mode WAIT

En mode WAIT (le mode par défaut), s’il y a un conflit avec des transactions concurrentes exécutant des mises à jour de données concurrentes dans la même base de données, cette transaction attendra que la transaction concurrente se termine en la confirmant (COMMIT) ou en l’annulant (ROLLBACK). En d’autres termes, l’application du client sera mise en attente jusqu’à ce que le conflit soit résolu.

Si LOCK TIMEOUT est spécifié pour le mode WAIT, l’attente ne durera que le nombre de secondes spécifié dans cette phrase. Après ce délai, un message d’erreur sera généré : “Lock time-out on wait transaction”.

Ce mode donne des comportements légèrement différents selon le niveau d’isolation des transactions.

Dans l’API Firebird, le mode WAIT correspond à la constante isc_tpb_wait.

docnext count = 19

Mode NO WAIT

Si le mode NO WAIT est défini, cette transaction lèvera immédiatement une exception de base de données si un conflit de verrou se produit.

Dans l’API Firebird, le mode NO WAIT correspond à la constante isc_tpb_nowait.

Note

L’option LOCK TIMEOUT est une option de transaction séparée mais ne peut être utilisée que pour les transactions WAIT. Spécifier LOCK TIMEOUT avec une transaction NO WAIT provoquera une erreur “invalid parameter in transaction parameter block -Option isc_tpb_lock_timeout is not valid if isc_tpb_nowait was used previously in TPB”.

ISOLATION LEVEL

Le niveau d’isolement d’une transaction est une valeur qui détermine le niveau auquel une transaction est autorisée à avoir des données incohérentes, c’est-à-dire le degré d’isolement d’une transaction par rapport à une autre. Les modifications apportées par un opérateur seront visibles pour tous les opérateurs suivants s’exécutant dans la même transaction, quel que soit son niveau d’isolement. Les modifications apportées dans une autre transaction restent invisibles pour la transaction actuelle jusqu’à ce qu’elles soient confirmées. Le niveau d’isolement, et parfois d’autres attributs, déterminent comment une transaction est isolée.

La clause optionnelle ISOLATION LEVEL spécifie le niveau d’isolation de la transaction en cours d’exécution. C’est la caractéristique la plus importante d’une transaction et elle détermine son comportement par rapport aux autres transactions concurrentes.

Il existe trois niveaux d’isolation des transactions :

  • SNAPSHOT

  • SNAPSHOT TABLE STABILITY

  • READ COMMITTED révisé (NO RECORD_VERSION ou RECORD_VERSION ou READ CONSISTENCY)

Niveau d’isolation SNAPSHOT

Le niveau d’isolement SNAPSHOT (le niveau d’isolement par défaut) signifie que seules les modifications qui ont été validées au plus tard au moment où cette transaction a démarré sont visibles pour cette transaction. Les modifications confirmées par d’autres transactions concurrentes ne seront pas visibles dans cette transaction pendant son activité sans la relancer. Pour voir ces modifications, la transaction doit être fermée (confirmée ou annulée complètement mais pas annulée au point de sauvegarde) et la transaction doit être relancée.

Note

Les modifications apportées par les transactions autonomes ne seront pas non plus visibles dans le contexte de la transaction ("externe") qui a lancé ces transactions autonomes si elle s’exécute en mode SNAPSHOT.

Dans l’API Firebird, le mode d’isolation SNAPSHOT correspond à la constante isc_tpb_concurrency.

Utilisation de AT NUMBER

Une transaction avec un niveau d’isolation SNAPSHOT peut être exécutée sur la base d’une autre transaction, si son numéro d’instantané est connu. Dans ce cas, cette nouvelle transaction peut voir les mêmes données que la transaction sur laquelle elle est exécutée.

Cette fonctionnalité permet de créer des processus parallèles (dans différentes connexions) qui lisent des données cohérentes à partir de la base de données. Par exemple, un processus de sauvegarde pourrait créer plusieurs threads qui lisent des données à partir de la base de données en parallèle. Ou un service Web pourrait travailler avec des services auxiliaires distribués pour effectuer certains traitements.

Pour ce faire, il faut créer une transaction en utilisant la syntaxe suivante

SET TRANSACTION SNAPSHOT  AT NUMBER snapshot_number

ou via l’API en utilisant la constante isc_tpb_at_snapshot_number.

La valeur de snapshot_number de la première transaction peut être récupérée en utilisant la requête suivante

RDB$GET_CONTEXT('SYSTEM', 'SNAPSHOT_NUMBER')

ou via l’API d’information sur les transactions avec la constante fb_info_tra_snapshot_number.

Note

Remarque : snapshot_number doit être le numéro de l’instantané de la transaction active.
Niveau d’isolation SNAPSHOT TABLE STABILITY

Le niveau d’isolation de la transaction SNAPSHOT TABLE STABILITY permet, comme dans le cas de `SNAPSHOT', de ne voir que les modifications qui ont été validées au plus tard au moment où cette transaction a commencé.Ainsi, dès qu’une telle transaction démarre, les autres transactions du client ne peuvent pas effectuer de modifications dans les tables de cette base de données déjà modifiées de quelque manière que ce soit par la première transaction.Toutes les tentatives de ce type dans des transactions simultanées entraîneront des exclusions de la base de données.Les autres transactions sont totalement libres de consulter toutes les données.

En utilisant l’offre de réservation RESERVING, il est possible d’autoriser d’autres transactions à modifier les données de certaines tables.

Si un client lance une transaction de niveau d’isolation SNAPSHOT TABLE STABILITY et qu’une autre transaction apporte une modification non approuvée à une table de la base de données, le lancement de la transaction de niveau d’isolation provoquera une erreur de base de données.

Dans l’API Firebird, le mode d’isolation SNAPSHOT TABLE STABILITY est représenté par la constante isc_tpb_consistency.

Niveau d’isolation READ COMMITTED

Le niveau d’isolation READ COMMITTED permet de voir toutes les modifications confirmées des données de la base de données effectuées dans d’autres transactions concurrentes dans une transaction sans la relancer. Les modifications non confirmées ne sont pas visibles dans les transactions de ce niveau d’isolation.

Pour obtenir une liste de lignes mise à jour pour une table d’intérêt, il suffit de réexécuter l’opérateur SELECT dans une transaction active READ COMMITTED sans la relancer.

Dans le mode d’isolation de l’API Firebird, READ COMMITTED correspond à la constante isc_tpb_read_committed.

RECORD_VERSION

Pour ce niveau d’isolement, l’une des deux valeurs caractéristiques supplémentaires peut être spécifiée, en fonction de la méthode de résolution des conflits souhaitée : RECORD_VERSION et NO RECORD_VERSION.Comme le montrent leurs noms, ils s’excluent mutuellement.

  • NO RECORD_VERSION est une sorte de mécanisme de verrouillage à deux phases. Dans ce cas, une transaction ne peut pas lire un enregistrement qui a été modifié par une transaction active concurrente (non confirmée).

    • Si la stratégie de résolution des verrouillages NO WAIT est spécifiée, une exception sera immédiatement levée.

    • Si la stratégie de résolution des verrouillages WAIT est spécifiée, elle fera en sorte qu’une transaction concurrente attende la fin ou le retour en arrière.Si une transaction concurrente est annulée ou si elle est terminée et que son identifiant est plus ancien (plus petit) que celui de la transaction en cours, les modifications de la transaction en cours sont autorisées.Si une transaction concurrente est terminée et que son identifiant est plus récent (plus grand) que l’identifiant de la transaction actuelle, une erreur de conflit de verrouillage sera générée.

  • Lorsque vous spécifiez RECORD_VERSION, la transaction lit toujours la dernière version validée des enregistrements de la table, qu’il existe ou non des versions modifiées et non validées de ces enregistrements. Dans ce cas, le mode de résolution du verrouillage (WAIT ou NO WAIT) n’a aucun effet sur le comportement de démarrage d’une transaction.

Dans l’API Firebird, le mode de résolution de conflit NO RECORD_VERSION est représenté par la constante isc_tpb_no_rec_version,et RECORD_VERSION — isc_tpb_rec_version.

Warning

A partir de Firebird 4.0, ces options sont obsolètes. Par défaut, elles sont ignorées et la transaction READ COMMITTED READ CONSISTENCY est lancée. Cela peut être modifié en mettant le ReadConsistency (voir firebird.conf) à 0. Dans ce cas, les options ne sont pas ignorées et fonctionnent exactement comme dans les versions précédentes. Dans les versions futures, ce paramètre dans firebird.conf peut être supprimé.
READ CONSISTENCY

Si cette option est spécifiée, la transaction en mode d’isolation READ COMMITED prend un instantané persistant de la base de données pour la durée de l’instruction. Chaque nouvelle instruction de niveau supérieur crée son propre instantané de la base de données pour voir les dernières données validées. Les instructions imbriquées (triggers, procédures et fonctions stockées imbriquées, instructions dynamiques, etc.) utilisent le même instantané de la base de données que celui créé par l’instruction de niveau supérieur.

Dans l’API Firebird, la constante isc_tpb_read_consistency correspond à l’opérateur READ CONSISTENCY pour un instantané cohérent au niveau SQL.

Gestion des conflits de mise à jour

Lorsqu’une instruction est exécutée dans une transaction en mode d’isolation READ COMMITTED READ CONSISTENCY, la vue de la base de données est inchangée (similaire à une transaction SNAPSHOT). Le comportement de lecture est similaire à celui de la transaction READ COMMITTED RECORD_VERSION — l’opérateur n’attend pas que la transaction active soit terminée et parcourt la chaîne arrière, qui recherche la version de l’enregistrement visible dans le snapshot courant.

Pour le mode d’isolation READ COMMITTED READ CONSISTENCY, la gestion des conflits de mise à jour de Firebird est considérablement modifiée. Lorsqu’un conflit de mise à jour est détecté, la procédure suivante est effectuée :

  1. le mode d’isolation de la transaction est temporairement commuté sur READ COMMITTED NO RECORD VERSION ;

  2. Firebird pose un verrou sur l’enregistrement en conflit ;

  3. Firebird continue à évaluer les enregistrements restants pour les supprimer/mettre à jour dans le curseur, et continue à poser des verrous sur eux ;

  4. lorsqu’il n’y a plus d’enregistrements à extraire, un mécanisme est déclenché pour annuler toutes les actions effectuées par l’opérateur de niveau supérieur, et tous les verrous posés pour chaque enregistrement mis à jour/supprimé/bloqué sont conservés, tous les enregistrements insérés sont supprimés ;

  5. alors Firebird restaure le mode d’isolation de la transaction en tant que READ COMMITTED READ CONSISTENCY, crée un nouvel instantané de niveau opérateur et relance l’exécution de l’instruction de niveau supérieur.

Cet algorithme garantit que, après le redémarrage, les enregistrements déjà mis à jour restent verrouillés, qu’ils sont visibles pour le nouvel instantané et qu’ils peuvent être mis à jour à nouveau sans autre conflit.De plus, grâce au mode de cohérence de lecture, l’ensemble des enregistrements modifiés reste cohérent.

Note
Remarques

  • L’algorithme de redémarrage ci-dessus s’applique aux opérateurs UPDATE, DELETE, SELECT WITH LOCK et MERGE, avec ou sans clause RETURNING, exécutés directement depuis l’application utilisateur ou en tant que partie d’un objet PSQL (procédure stockée, fonction, déclencheur, EXECUTE BLOCK etc ;)

  • Si un opérateur de haut niveau UPDATE/DELETE est situé à un curseur explicite (WHERE CURRENT OF), Firebird saute l’étape (c) ci-dessus, c’est-à-dire qu’il ne récupère pas et ne pose pas de verrous pour les enregistrements restants du curseur ;

  • Si une instruction SELECT de niveau supérieur (ou un ensemble de données de retour EXECUTE BLOCK) et un conflit de mise à jour se produisent après qu’un ou plusieurs enregistrements ont été renvoyés à l’application, l’erreur de conflit de mise à jour est signalée comme normale et un redémarrage n’est pas lancé ;

  • le redémarrage n’est pas initié pour les opérateurs en blocs autonomes (IN AUTONOMOUS TRANSACTION DO …​) ;

  • après 10 tentatives, Firebird abandonne l’algorithme de redémarrage, supprime tous les verrous d’écriture, restaure le mode d’isolation de la transaction en tant que READ COMMITTED READ CONSISTENCY et signale un conflit de mise à jour ;

  • toute erreur non traitée à l’étape (c) ci-dessus arrête l’algorithme de redémarrage et Firebird continue le traitement de manière normale, c’est-à-dire que l’erreur peut être interceptée et traitée par le bloc PSQL WHEN ou signalée à l’application si elle n’est pas traitée ;

  • Les déclencheurs UPDATE/DELETE seront déclenchés plusieurs fois pour le même enregistrement si l’exécution de la déclaration a été relancée et l’enregistrement mis à jour/supprimé à nouveau ;

  • pour des raisons historiques, isc_update_conflict est signalé comme un code d’erreur secondaire avec le code d’erreur primaire isc_deadlock.

NO AUTO UNDO

Lorsque vous utilisez l’option NO AUTO UNDO, l’instruction ROLLBACK marque seulement la transaction comme étant annulée sans supprimer les versions créées dans cette transaction, qui seront supprimées plus tard selon la politique de collecte des déchets sélectionnée (voir le paramètre GCPolicy dans firebird.conf).

Cette option peut être utile pour une transaction dans laquelle de nombreuses déclarations individuelles modifiant les données sont effectuées, et il est certain que la transaction se terminera le plus souvent avec succès plutôt que d’être annulée.

Pour les transactions dans lesquelles aucune modification n’est effectuée, l’option NO AUTO UNDO est ignorée.

IGNORE LIMBO

L’option IGNORE LIMBO ignore les enregistrements créés par des transactions lost (c’est-à-dire non complétées) (transaction limbo). Une transaction est considérée comme "perdue" si le deuxième commit en deux phases n’a pas été effectué.

AUTO COMMIT

Si l’option AUTO COMMIT est spécifiée, la transaction est automatiquement confirmée après l’exécution d’une instruction. Si une erreur se produit pendant l’exécution de l’instruction, la transaction sera annulée. Après confirmation ou annulation, la transaction continue d’être active, en conservant son identifiant.

Important

L’option AUTO COMMIT utilise une confirmation soft (COMMIT RETAIN) et un rollback soft (ROLLBACK RETAIN) de la transaction. La confirmation soft ne libère pas les ressources du serveur et retarde la collecte des déchets, ce qui peut avoir un impact négatif sur les performances.

RESERVING

La clause RESERVING de l’instruction SET TRANSACTION réserve les tables spécifiées dans la liste.La réservation interdit aux autres transactions d’apporter des modifications à ces tables ou (sous certains paramètres de caractéristique de la phrase de réservation) même de lire les données de ces tables pendant que cette transaction est en cours d’exécution.Alternativement, dans cette proposition, vous pouvez spécifier une liste de tables qui peuvent être modifiées par des transactions concurrentes même si une transaction de niveau d’isolation SNAPSHOT TABLE STABILITY est lancée.

Vous pouvez spécifier un nombre arbitraire de tables réservées de la base de données utilisée dans une seule phrase de redondance.

Si l’un des mots-clés SHARED ou PROTECTED est omis, SHARED est supposé.Si la phrase entière FOR est omise, FOR SHARED READ est supposé.Les options de mise en œuvre des réservations de tables par leur nom ne sont pas évidentes.

Table 1. Compatibilité des différents verrouillages

 

SHARED READ

SHARED WRITE

PROTECTED READ

PROTECTED WRITE

SHARED READ

oui

oui

oui

oui

SHARED WRITE

oui

oui

non

non

PROTECTED READ

oui

non

oui

non

PROTECTED WRITE

oui

non

non

non

Pour une transaction s’exécutant en mode d’isolation SNAPSHOT pour les tables spécifiées dans la phrase RESERVING, les comportements suivants sont autorisés dans les transactions concurrentes en fonction de leur niveau d’isolation avec différentes méthodes de réservation :

  • SHARED READ — n’a aucun effet sur l’exécution de transactions concurrentes ;

  • SHARED WRITE — n’a aucun effet sur le comportement des transactions parallèles avec les niveaux d’isolation SNAPSHOT et READ COMMITTED ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit non seulement l’écriture mais aussi la lecture des données des tables spécifiées ;

  • PROTECTED READ - permet uniquement de lire les données des tables réservées pour les transactions simultanées avec n’importe quel niveau d’isolation ; toute tentative de modification entraîne l’exclusion de la base de données ;

  • PROTECTED WRITE — pour les transactions parallèles avec les niveaux d’isolation SNAPSHOT et READ COMMITTED, il interdit l’écriture dans les tables spécifiées ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit également la lecture des données de la table de réservation.

Pour une transaction démarrée dans le mode d’isolation SNAPSHOT TABLE STABILITY pour les tables spécifiées dans la phrase RESERVING, dans les transactions parallèles, selon leur niveau d’isolation, les variantes de comportement suivantes sont acceptables aux différentes méthodes de leur réservation :

  • SHARED READ — permet à toutes les transactions concurrentes, quel que soit leur niveau d’isolation, non seulement de lire mais aussi d’effectuer des modifications dans les tables réservées (si la transaction concurrente a le mode d’accès READ WRITE) ;

  • SHARED WRITE — pour toutes les transactions concurrentes avec le niveau d’accès READ WRITE et avec les niveaux d’isolation SNAPSHOT et READ COMMITTED, il permet de lire les données des tables et d’écrire les données dans les tables spécifiées ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit non seulement d’écrire mais aussi de lire les données des tables spécifiées ;

  • PROTECTED READ - permet de lire uniquement les données des tables réservées pour les transactions parallèles avec n’importe quel niveau d’isolation ;

  • PROTECTED WRITE — pour les transactions parallèles avec le niveau d’isolation SNAPSHOT et READ COMMITTED, il interdit l’écriture dans les tables spécifiées ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit également la lecture des données des tables de réservation.

Pour une transaction démarrée dans le mode d’isolation READ COMMITTED pour les tables spécifiées dans la phrase RESERVING, dans les transactions parallèles, en fonction de leur niveau d’isolation, les variantes de comportement suivantes sont acceptables aux différentes méthodes de leur réservation :

  • SHARED READ — permet à toutes les transactions concurrentes, quel que soit leur niveau d’isolation, non seulement de lire mais aussi d’effectuer toute modification dans les tables réservées (au niveau d’accès READ WRITE) ;

  • SHARED WRITE — pour toutes les transactions avec le niveau d’accès READ WRITE et avec les niveaux d’isolation SNAPSHOT et READ COMMITTED, il autorise la lecture et l’écriture de données dans les tables spécifiées ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit non seulement l’écriture mais aussi la lecture de données depuis les tables spécifiées ;

  • PROTECTED READ — permet seulement de lire les données des tables réservées pour les transactions parallèles avec n’importe quel niveau d’isolation ;

  • PROTECTED WRITE — pour les transactions parallèles avec les niveaux d’isolation SNAPSHOT et READ COMMITTED, permet uniquement la lecture des données et interdit l’écriture dans les tables spécifiées dans cette liste ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit non seulement la modification des données mais aussi la lecture des données des tables de réservation.

Tip

La proposition USING peut être utilisée pour économiser les ressources du système en limitant le nombre de bases de données auxquelles une transaction peut accéder. Disponible uniquement dans Embedded SQL.
Voir aussi :

COMMIT, ROLLBACK.

COMMIT

affectation

Confirmation de la transaction.

Disponible en

DSQL, ESQL

Syntaxe
COMMIT [WORK] [TRANSACTION tr_name]
  [RELEASE] [RETAIN [SNAPSHOT]];
Table 1. Paramètres de l’opérateur COMMIT
Paramètre Description

tr_name

Nom de la transaction. Disponible uniquement dans ESQL.

L’instruction COMMIT confirme toutes les modifications de données effectuées dans le cadre de cette transaction (ajouts, modifications, suppressions). Les nouvelles versions des enregistrements deviennent disponibles pour les autres transactions, et si la clause RETAIN n’est pas utilisée, toutes les ressources du serveur associées à l’exécution de cette transaction sont libérées.

Si une erreur de base de données se produit au cours du processus de validation de la transaction, celle-ci n’est pas validée. Le programme utilisateur doit gérer la situation d’erreur et revalider la transaction ou l’annuler.

La clause optionnelle TRANSACTION spécifie le nom de la transaction. La clause TRANSACTION n’est disponible que dans Embedded SQL. Si la clause TRANSACTION n’est pas spécifiée, l’instruction COMMIT est appliquée à la transaction par défaut.

Note

Les transactions nommées permettent d’exécuter simultanément plusieurs transactions actives dans la même application. Une variable du langage de base portant le même nom doit être déclarée et initialisée. En DSQL, cette restriction empêche la spécification dynamique des noms de transaction.

Le mot-clé facultatif WORK ne peut être utilisé que pour des raisons de compatibilité avec d’autres systèmes de gestion de bases de données relationnelles.

Le mot-clé RELEASE n’est disponible que dans Embedded SQL. Il vous permet de vous déconnecter de toutes les bases de données après la fin de la transaction en cours. Le mot-clé RELEASE n’est supporté que pour des raisons de compatibilité avec les anciennes versions d’Interbase. L’instruction ESQL DISCONNECT est maintenant utilisée à la place.

Si la phrase RETAIN [SNAPSHOT] est utilisée, une validation douce est effectuée. Les actions effectuées dans le cadre de cette transaction sont validées dans la base de données et la transaction elle-même reste active, conservant son identifiant ainsi que l’état du curseur qu’elle avait avant la validation douce. Dans ce cas, il n’est pas nécessaire de relancer la transaction et de réexécuter l’instruction SELECT pour récupérer les données.

Si le niveau d’isolation SNAPSHOT ou SNAPSHOT TABLE STABILITY d’une telle transaction, après le soft commit, la transaction continue à voir l’état de la base de données qui était au début de la transaction, c’est-à-dire que le programme client ne voit pas les résultats nouvellement confirmés de la modification des données d’autres transactions. De plus, le soft commit ne libère pas les ressources du serveur (les curseurs ouverts ne sont pas fermés).

Tip

Pour les transactions qui ne font que lire des données dans la base de données, il est également recommandé d’utiliser l’opérateur COMMIT plutôt que ROLLBACK, car cette option nécessite moins de ressources serveur et améliore les performances de toutes les transactions suivantes.
Voir aussi :

SET TRANSACTION, ROLLBACK.

ROLLBACK

affectation

Annulez la transaction.

Disponible en

DSQL, ESQL

Syntaxe
ROLLBACK [WORK] [TRANSACTION tr_name]
  [RETAIN [SNAPSHOT] | TO SAVEPOINT sp_name] [RELEASE];
Table 1. Paramètres de l’opérateur ROLLBACK
Paramètre Description

tr_name

Nom de la transaction. Disponible uniquement dans ESQL.

sp_name

Le nom du point de sauvegarde, disponible uniquement dans DSQL.

L’instruction ROLLBACK annule tous les changements de données de la base de données (ajouts, modifications, suppressions) effectués dans le contexte de cette transaction. L’instruction ROLLBACK ne provoque jamais d’erreurs. Si l’instruction RETAIN n’est pas spécifiée, elle libère toutes les ressources du serveur associées à l’exécution de cette transaction.

La clause optionnelle TRANSACTION spécifie le nom de la transaction. La clause TRANSACTION n’est disponible que dans Embedded SQL. Si la clause TRANSACTION n’est pas spécifiée, l’instruction ROLLBACK s’applique à la transaction par défaut.

Note

Les transactions nommées permettent à plusieurs transactions actives de s’exécuter simultanément dans la même application. Une variable du langage de base portant le même nom doit être déclarée et initialisée. En DSQL, cette restriction empêche la spécification dynamique des noms de transaction.

Le mot-clé facultatif WORK ne peut être utilisé que pour des raisons de compatibilité avec d’autres systèmes de gestion de bases de données relationnelles.

Le mot-clé RETAIN indique que toutes les actions de modification des données dans le contexte de cette transaction sont annulées et que la transaction elle-même continue d’être active, conservant son identifiant ainsi que l’état du curseur qu’elle avait avant que la transaction ne soit soft-committed. Ainsi, les ressources allouées à la transaction ne sont pas libérées.

Pour les niveaux d’isolation SNAPSHOT et SNAPSHOT TABLE STABILITY, l’état de la base de données reste tel qu’il était lorsque la transaction a été initialement lancée, mais dans le cas du niveau d’isolation READ COMMITTED, la base de données sera telle qu’elle était lorsque l’instruction ROLLBACK RETAIN a été exécutée. Si une transaction est annulée tout en conservant son contexte, il n’est pas nécessaire de réexécuter l’instruction SELECT pour récupérer les données de la table.

Voir aussi :

SET TRANSACTION, COMMIT.

ROLLBACK TO SAVEPOINT

La clause optionnelle TO SAVEPOINT de l’instruction ROLLBACK spécifie le nom du point de sauvegarde vers lequel le rollback se produit.Dans ce cas, toutes les modifications effectuées dans la transaction à partir du point de sauvegarde créé (SAVEPOINT) sont annulées.

L’opérateur ROLLBACK TO SAVEPOINT effectue les opérations suivantes :

  • Toutes les modifications de la base de données effectuées dans la transaction à partir du point de sauvegarde créé sont annulées. Les variables utilisateur définies avec RDB$SET_CONTEXT() restent inchangées ;

  • Tous les points de sauvegarde créés après le point de sauvegarde nommé sont détruits. Tous les points de sauvegarde antérieurs, comme le point de sauvegarde lui-même, sont conservés. Cela signifie qu’il est possible de revenir plusieurs fois au même point de sauvegarde ;

  • Tous les enregistrements verrouillés explicites et implicites du point de sauvegarde sont libérés. Les autres transactions qui ont précédemment demandé l’accès aux lignes verrouillées après le point de sauvegarde doivent continuer à attendre jusqu’à ce que la transaction soit validée ou annulée. D’autres transactions qui n’ont pas encore demandé l’accès à ces rangées peuvent demander et accéder immédiatement aux rangées déverrouillées.

Voir aussi :

SAVEPOINT.

SAVEPOINT

affectation

Création d’un point de sauvegarde.

Disponible en

DSQL

Syntaxe
SAVEPOINT sp_name
Table 1. Paramètres de l’opérateur SAVEPOINT
Paramètre Description

sp_name

Nom du point de sauvegarde, qui doit être unique dans la transaction.

L’instruction SAVEPOINT crée un point de sauvegarde compatible avec SQL:99 auquel les opérations de la base de données peuvent être ramenées ultérieurement sans annuler les actions effectuées depuis le début de la transaction. Les mécanismes de point de sauvegarde sont également connus sous le nom de transactions imbriquées.

Si un nom de point de sauvegarde existe déjà dans une transaction, le point de sauvegarde existant sera supprimé et un nouveau sera créé avec le même nom.

Pour annuler les modifications apportées au point de sauvegarde, on utilise l’opérateur ROLLBACK TO SAVEPOINT.

Note

Le mécanisme de point de sauvegarde interne peut utiliser de grandes quantités de mémoire, surtout si vous mettez à jour les mêmes enregistrements plusieurs fois dans la même transaction. Si un point de sauvegarde n’est plus nécessaire, mais que vous n’êtes pas encore prêt à terminer la transaction, vous pouvez le supprimer avec l’opérateur RELEASE SAVEPOINT, libérant ainsi des ressources.
Example 1. DSQL session utilisant des points de sauvegarde
CREATE TABLE TEST (ID INTEGER);
COMMIT;
INSERT INTO TEST VALUES (1);
COMMIT;
INSERT INTO TEST VALUES (2);
SAVEPOINT Y;
DELETE FROM TEST;
SELECT * FROM TEST; -- renvoie une chaîne vide
ROLLBACK TO Y;
SELECT * FROM TEST; -- renvoie deux lignes
ROLLBACK;
SELECT * FROM TEST; -- renvoie une seule ligne
Voir aussi :

ROLLBACK TO SAVEPOINT, RELEASE SAVEPOINT.

RELEASE SAVEPOINT

affectation

Suppression d’un point de sauvegarde.

Disponible en

DSQL

Syntaxe
RELEASE SAVEPOINT sp_name [ONLY]
Table 1. Paramètres de l’opérateur RELEASE SAVEPOINT
Paramètre Description

sp_name

Le nom du point de sauvegarde.

L’instruction RELEASE SAVEPOINT supprime le point de sauvegarde nommé, libérant toutes les ressources associées. Par défaut, tous les points de sauvegarde créés après celui spécifié sont également supprimés. Si la clause ONLY est spécifiée, seul le point de sauvegarde portant le nom spécifié est supprimé.

Voir aussi :

SAVEPOINT.

Points de sauvegarde internes

Par défaut, le serveur utilise un point de sauvegarde automatique au niveau de la transaction pour annuler la transaction. Lorsque l’instruction ROLLBACK est exécutée, toutes les modifications apportées à la transaction sont annulées au point de sauvegarde du système, puis la transaction est approuvée.

Lorsque le nombre de modifications effectuées sous le point de sauvegarde au niveau de la transaction devient important (environ 50 000 enregistrements sont concernés), le serveur libère le point de sauvegarde système et utilise le mécanisme TIP pour annuler la transaction si nécessaire.

Tip

Si vous vous attendez à ce que le volume des changements dans une transaction soit important, vous pouvez définir l’option NO AUTO UNDO dans l’instruction SET TRANSACTION, ou — si vous utilisez l’API — définir l’indicateur TPB isc_tpb_no_auto_undo. Les deux options empêchent la création d’un point de transaction de niveau sauvegarde système.

Points de sauvegarde et PSQL

L’utilisation d’instructions de contrôle de transaction dans PSQL n’est pas autorisée car elle romprait l’atomicité de l’instruction appelant la procédure.Mais Firebird supporte l’appel et la gestion des exceptions dans PSQL, de sorte que les actions effectuées dans les procédures stockées et les triggers peuvent être annulées de manière sélective sans annuler complètement toutes les actions qu’ils contiennent.En interne, les points de sauvegarde automatique sont utilisés pour :

  • Annuler toutes les actions à l’intérieur du `BEGIN …​ END' où une exception se produit ;

  • Annuler toutes les actions effectuées dans une procédure stockée ou un déclencheur (ou, dans le cas d’une procédure stockée sélective, toutes les actions effectuées depuis la dernière instruction SUSPEND) si elles se terminent prématurément à cause d’une erreur ou d’une exception involontaire.

Chaque bloc de traitement des exceptions PSQL est également limité aux points de sauvegarde automatique du serveur.

Note

Le bouton "DEBUT …​ END` ne crée pas de point de sauvegarde automatique. Il est seulement créé dans les blocs qui ont un bloc WHEN pour gérer les exceptions ou les erreurs.