Technique 4: Accès concurrent

l’enregistrement est maintenu jusqu’à  ce qu’une opération ultérieure de mise
à  jour de l’enregistrement, une autre opération de lecture pour mise à  jour du
même fichier, ou une instruction d’exécution ou de repositionnement termine la
transaction.

Pour utiliser le verrouillage d’enregistrement en SQL, il suffit d’ajouter une
clause For Update Of à  la déclaration de curseur, et d’utiliser une instruction
Update positionnée (j’en parle plus longuement plus haut), après exécution d’une
instruction Fetch pour extraire un enregistrement avec le curseur.Pour la plupart
des applications interactives, il vaut mieux opter pour une autre technique, connue
sous le nom de stratégie « optimiste »

Lorsqu’une application verrouille un enregistrement et maintient ce verrouillage
pendant que l’utilisateur passe en revue et risque de modifier les données de
manière interactive, elle utilise ce que l’on appelle une stratégie de concurrence
d’accès pessimiste ( » pessimiste  » parce qu’elle s’attend à  ce qu’une autre application
tente une mise à  jour conflictuelle, alors que l’enregistrement est en train d’être
traité). Les stratégies de concurrence d’accès pessimistes risquent d’accroître
les conflits d’accès aux enregistrements entre travaux et ne sont généralement
pas la meilleure approche pour les transactions impliquant un  » temps de réflexion
 » ou un délai de la part de l’utilisateur. La concurrence d’accès pessimiste ne
fonctionne pas bien non plus avec les applications livrées sur le Web, où les
connexions aux bases de données ne devraient pas durer longtemps.
Pour la plupart des applications interactives, il vaut mieux opter pour une autre
technique, connue sous le nom de stratégie « optimiste ». Pour simplifier, disons
que l’application lit au départ un enregistrement sans le verrouiller, mais qu’avant
de mettre à  jour l’enregistrement dans le fichier, elle s’assure que celui-ci
n’a pas été modifié depuis son extraction. En RPG IV, cette technique nécessite
six étapes de base :

1. En cartes F, déclarez le fichier comme étant utilisé pour des opérations de
mise à  jour (codez un U en position 17).
2. Utilisez l’extension de code opération N (pas de verrou) sur l’opération Chain,
Read, ou toute autre opération d’entrée initiale pour lire l’enregistrement sans
verrou.
3. Faites une copie de l’enregistrement tel qu’il est lu au départ.
4. Avant de mettre à  jour l’enregistrement, relisez-le sans extension N, ce qui
le verrouille. (Si l’enregistrement est alors verrouillé par un autre travail,
lorsque vous essayez de le relire, vous pouvez aussi choisir de réessayer cette
étape plusieurs fois. Si l’enregistrement reste verrouillé par un autre travail,
traitez la situation comme une exception et redémarrez la transaction. Notez que
les conflits de verrouillage ne devraient se produire que rarement si toutes les
applications évitent de maintenir longtemps les enregistrements verrouillés).

5. Comparez la copie originale sauvegardée et l’enregistrement relu.
6. S’ils sont identiques, mettez à  jour l’enregistrement extrait avec verrouillage.
Sinon, traitez l’exception et redémarrez la transaction.

En SQL, cette technique peut être mise en oeuvre avec un curseur en lecture seule
pour l’étape 2 et un curseur actualisable pour les étapes 4 et 6. Mais il existe
une alternative plus simple. Commencez par lire l’enregistrement sans verrouillage
grâce à  une instruction Select Into ou un curseur en lecture seule. Ces opérations
stockent toutes deux les valeurs de colonnes dans des variables hôtes. Puis, pour
l’opération de mise à  jour, utilisez une instruction Update de recherche comme
celle de la figure 4.
Dans cet exemple, on utilise une instruction Select Into ou Fetch pour extraire
les zones d’un enregistrement et les placer dans les variables hôtes KeyFld, Fld1,
Fld2, …, FldN. Le programme place les nouvelles valeurs dans les variables hôtes
NewFld1, NewFld2, …, NewFldN. Après l’instruction Update, le programme devrait
vérifier l’état SQL, qui aura la valeur SqlStateNoRow, si aucune des zones testées
dans la clause Where ne correspond aux valeurs qu’elles avaient lors de l’extraction
de l’enregistrement.
Notez qu’avec cette technique, il faudrait toujours extraire la (ou les) zone(s)
de clé primaire pour identifier de manière unique l’enregistrement dans l’instruction
Update. Il n’y a pas à  extraire et à  contrôler toutes les zones sans clés de l’enregistrement,
mais uniquement celles qui sont utilisées dans la transaction. En fait, si peu
importe qu’une zone ait été modifiée ou pas, avant d’exécuter la transaction,
il n’est pas nécessaire de l’extraire ou de la contrôler. Bien entendu, il ne
faut pas mettre à  jour une zone qui n’a pas été d’abord vérifiée.

Les quatre techniques de programmation que je viens de décrire peuvent aider le
programmeur RPG qui souhaite utiliser SQL à  répondre à  la plupart des exigences
des applications les plus communes. Des variantes de ces techniques peuvent couvrir
beaucoup d’autres situations.