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.