FirebirdSQL logo
 COMMENTSInstructions de procédure SQL (PSQL) 

Comment le serveur fonctionne avec WITH LOCK

Tenter de modifier un enregistrement avec une instruction UPDATE verrouillée par une autre transaction déclenche une exception de conflit de mise à jour ou l’attente de la fin de la transaction de verrouillage - selon le mode TPB. Le comportement du serveur est ici le même que si l’enregistrement avait déjà été modifié par la transaction de verrouillage.

Il n’y a pas de gdscode spécial renvoyé pour les conflits de mise à jour liés à une transaction de verrouillage pessimiste.

Le serveur garantit que tous les enregistrements renvoyés par l’instruction de verrouillage explicite sont effectivement verrouillés et correspondent aux conditions de recherche spécifiées dans l’instruction WHERE si ces conditions ne dépendent d’aucune autre table, s’il n’y a pas d’instructions de jointure, de sous-requêtes, etc.

Note

Cette situation peut se produire si une autre transaction concurrente confirme un changement dans l’exécution de la déclaration de verrouillage actuelle.

Le serveur verrouille les lignes au fur et à mesure qu’elles sont échantillonnées, ce qui a des conséquences importantes si vous verrouillez plusieurs lignes à la fois. De nombreuses méthodes d’accès aux bases de données Firebird utilisent des paquets de plusieurs centaines de lignes (appelés "tampon d’échantillonnage") pour échantillonner les données par défaut. La plupart des composants d’accès aux données ne sélectionnent pas les lignes contenues dans le dernier paquet reçu, et pour lesquelles un conflit de mise à jour s’est produit.

Précautions à prendre lors de l’utilisation WITH LOCK

  • Le retour en arrière d’un point de sauvegarde implicite ou explicite annule le verrouillage des enregistrements qui ont été modifiés dans le cadre de son action, mais les transactions en attente ne sont pas notifiées de la fin du verrouillage. Les applications ne doivent pas dépendre de ce comportement car il peut être modifié à l’avenir ;

  • Bien que les verrous explicites puissent être utilisés pour prévenir et/ou traiter les erreurs inhabituelles de conflit de mise à jour, le nombre d’erreurs de mise à jour (deadlocks) augmentera si vous ne concevez pas soigneusement votre stratégie de verrouillage et ne la gérez pas étroitement ;

  • La plupart des applications ne nécessitent pas de verrouillage explicite des enregistrements. Les principaux objectifs du verrouillage explicite sont les suivants :

    • pour éviter le traitement coûteux des erreurs de conflit de mise à jour dans les applications fortement chargées

    • pour maintenir l’intégrité des objets mappés à partir d’une base de données relationnelle dans un environnement en grappe. Si votre utilisation du verrouillage explicite n’entre pas dans l’une de ces deux catégories, alors c’est la mauvaise façon de résoudre les problèmes dans Firebird ;

  • Le verrouillage explicite est une fonction avancée ; n’en abusez pas ! Bien que le verrouillage explicite puisse être très important pour les sites web traitant des milliers de transactions d’écriture simultanées, ou pour des systèmes tels que ERP/CRM fonctionnant dans de grandes entreprises, la plupart des applications ne nécessitent pas son utilisation.

Exemples d’utilisation du blocage explicite

Example 1. Blocage d’une seule entrée
SELECT *
FROM DOCUMENT
WHERE DOCUMENT_ID=? WITH LOCK
Example 2. Verrouillage de plusieurs enregistrements avec leur curseur DSQL séquentiel :
SELECT *
FROM DOCUMENT
WHERE PARENT_ID=?
FOR UPDATE WITH LOCK

OPTIMIZE FOR

Affectation

Changer la stratégie de l’optimiseur.

Синтаксис
SELECT ...
FROM [...]
[WHERE ...]
[...]
[OPTIMIZE FOR {FIRST | ALL} ROWS]

La clause OPTIMIZE FOR vous permet de changer la stratégie de l’optimiseur au niveau de la requête SQL courante.Elle ne peut apparaître que dans l’instruction SELECT de la requête SQL de niveau supérieur.

Il existe deux stratégies d’optimisation des requêtes :

  • FIRST ROWS - l’optimiseur construit le plan de requête pour ne récupérer que les premières lignes de la requête de la manière la plus rapide ;

  • ALL ROWS - l’optimiseur construit le plan de requête pour récupérer toutes les lignes de la requête le plus rapidement possible.

Dans la plupart des cas, une stratégie d’optimisation ALL ROWS' est nécessaire. Cependant, si vous avez des applications avec des grilles de données,dans lesquelles seules les premières lignes du résultat sont affichées et les autres sont récupérées en fonction des besoins, la stratégie `FIRST ROWS peut être préférable car elle réduit le temps de déconnexion.

Par défaut, la stratégie d’optimisation spécifiée dans le paramètre OptimizeForFirstRows du fichier de configuration est utiliséefirebird.conf ou database.conf. OptimiseForFirstRows = false correspond à la stratégie ALL ROWS,OptimiseForFirstRows = true correspond à la stratégie First ROWS.

La stratégie d’optimisation peut également être modifiée au niveau de la session à l’aide de l’opérateur SET OPTIMIZE.La clause OPTIMIZE FOR spécifiée dans l’instruction SQL vous permet de remplacer la stratégie spécifiée au niveau de la session.

La clause OPTIMIZE FOR spécifie toujours la clause OPTIMIZE FOR la plus récente dans une requête SELECT, mais avant la clause INTO.

Note

Si la requête SELECT contient FIRST …​ SKIP, ROWS, OFFSET …​ FETCH, l’optimiseur passe implicitement au mode FIRST ROWS.

INTO

affectation

Transférer les résultats de SELECT dans des variables.

Disponible en:

PSQL

Syntaxe:
SELECT [...] <column-list>
FROM ...
[...]
[INTO <variable-list>]

<variable-list> ::= [:]psqlvar [, [:]psqlvar ...]

En PSQL (procédures stockées, triggers, etc.) les résultats d’une commande SELECT peuvent être chargés ligne par ligne dans des variables locales (le nombre, l’ordre et les types de variables locales doivent correspondre aux champs SELECT). Souvent, un tel chargement est le seul moyen de faire quelque chose avec les valeurs de retour.

L’instruction SELECT simple ne peut être utilisé dans PSQL que s’il ne retourne pas plus d’une chaîne de caractères, c’est-à-dire s’il s’agit d’une requête unique. Pour les requêtes qui retournent plusieurs chaînes de caractères, PSQL suggère d’utiliser l’instruction FOR SELECT.

Important

Lorsque la requête ne renvoie aucune donnée (zéro ligne), les valeurs des variables de la liste INTO ne sont pas modifiées.

De plus, PSQL prend en charge l’instruction DECLARE CURSOR, qui associe un curseur nommé à une commande SELECT particulière — et ce curseur peut alors être utilisé pour naviguer dans l’ensemble de données retourné.

En PSQL, la clause INTO doit apparaître à la toute fin de la commande SELECT.

Important
Veuillez noter.

En PSQL, les deux points avant les noms de variables sont facultatifs.

Exemples

Dans PSQL, vous pouvez attribuer les valeurs de min_amt, avg_amt et max_amt à des variables prédéfinies ou à des paramètres de sortie :

SELECT
  MIN(amount),
  AVG(CAST(amount AS float)),
  MAX(amount)
FROM orders
WHERE artno = 372218
INTO min_amt,
     avg_amt,
     max_amt;

Dans cette requête, CAST est utilisé pour calculer correctement la valeur moyenne. Si la valeur n’est pas convertie en float, la valeur moyenne sera tronquée à la valeur entière la plus proche.

Dans le déclencheur :

SELECT LIST(name, ', ')
FROM persons p
WHERE p.id IN (new.father, new.mother)
INTO new.parentnames;