La gestion des mises à jour concurrentes

[Dylav]

LA GESTION DES MISES A JOUR CONCURRENTES

Mettons tout de suite les choses au point, les techniciens pressés peuvent se rendre directement au chapitre Partir gagnant, mais j’ai l’intime conviction qu’ils regretteront un jour de n’avoir pas tout lu.

Au sommaire,

• Un peu d’histoire
• L’arrivée de l’ordinateur
• Le temps réel
• Les bases de données
• Les dispositifs de verrouillage
• Partir gagnant
• Mais quel intérêt pour mon site ?

Un peu d’histoire

Dans l’antiquité, enfin je veux dire jusqu’au milieu du siècle dernier… pour des raisons légales, réglementaires ou pratiques, une entreprise se devait de garder trace (l’obligation de la preuve), des tractations avec chacun de ses clients, auquel elle ouvrait donc un dossier. Oui, une chemise cartonnée, avec une sangle ou un rabat, selon les habitudes de la maison, éventuellement structurée en sous-chemises de couleur.

Lors de chaque acte de gestion, que ce soit à l’initiative du client (changement d’adresse, de RIB) ou à l’occasion d’un renouvellement, le gestionnaire demandait au service Archives de lui sortir le dossier, au vu duquel il appréciait le travail à exécuter, dont il laissait une trace circonstanciée dans ce même dossier qu’il retournait ensuite à l’archiviste.

Si par hasard un autre événement survenait pendant ce traitement, et était pris en charge par un autre gestionnaire, l’archiviste sollicité répondait que le dossier était en mains, et notre second gestionnaire mettait son événement sous le coude en attendant un moment plus propice.

Du point de vue du dossier, il était mis en file d’attente, comme au guichet de la Sécu : un seul intervenant à la fois !

L’arrivée de l’ordinateur

Les années 60 ont vu se répandre un nouvel outil de gestion, qu’on appelait ordinateur. Le travail du gestionnaire en a été considérablement modifié !

En effet, outre le problème à dénouer en demandant le dossier pour le consulter, le mettre à jour et le restituer aux Archives, il s’est vu attribuer la tâche supplémentaire de remplir un bordereau de saisie (plein de petites cases, n’écrire qu’un caractère par case, et tout en majuscules SVP), destiné à mettre à jour le dossier informatique du client, progrès oblige !

Le bordereau était ensuite confié à une encodeuse (souvent de jolies filles, si si, qu’on appelait aussi perfos), qui tapotait alors un clavier produisant des confettis en trouant des petits rectangles cartonnés fort justement surnommés cartes perforées. Les paquets de cartes étaient ensuite avalés par l’ordinateur, qui savait lire les trous pour effectuer une mise à jour circonstanciée du dossier informatisé du client.

Chaque nuit, l’ordinateur ruminait tous ces trous qu’on lui avait fait ingurgiter et, le matin, notre gestionnaire, comme tous ses collègues, recevait la liste (le listing) de toutes les fautes qu’il avait commises la veille (on dit des anomalies).

C’était du temps des Trente Glorieuses, on assurait le plein emploi...

Pour les mises à jour concurrentes, pas de souci. La machine ne mangeait qu’une carte perforée à la fois, et l’informaticien, qui avait eu à expliquer à l’engin comment digérer les trous sans faire d’aérophagie, lui avait également enseigné à retrouver le dossier concerné plusieurs fois par nuit s’il le fallait, mais ce n’était jamais en même temps : même une machine n’a que deux bras !

Le temps réel

Avec les années 70, nous sortons presque de la préhistoire, quoique... beaucoup d’entre nous n’étaient pas encore nés.

Les traitements différés de la décennie précédente (qu’on appelle aussi batchs) vont connaître de la concurrence. Progrès oblige, les ordinateurs deviennent de plus en plus intelligents et rapides. Ils fonctionnent tellement vite qu’ils donnent même l’impression de faire plusieurs choses à la fois.

On a en tout cas demandé à notre gestionnaire de libérer un peu de place sur son bureau, pour y installer un écran et un clavier. Pas trop content, notre gestionnaire. Plus de place pour travailler. On me prend pour une secrétaire. Etc.

La nouvelle procédure lui indique qu’il n’aura plus à remplir de bordereau, puisqu’on lui a préparé à l’écran un formulaire similaire (mais pas vraiment présenté pareil, ce serait trop facile), qu’il pourra directement remplir à l’aide du clavier.

Ce qui est agaçant, se dit le gestionnaire, c’est que je me fais rappeler à l’ordre à chaque fois que je commets une erreur. Mais, ajoute-t-il en son for intérieur, ce qui est sympathique, c’est que je la corrige tout de suite et qu’on n’en parlera plus demain (que tu crois !).

C’est ce que l’on a baptisé temps réel, ou TP (temps partagé), par opposition aux travaux différés.

On a fait un petit pas vers le zéro papier. Mais justement, pour le dossier papier… eh bien, le monde a changé. Enfin, un peu ! Il reste l’obligation légale ou réglementaire de la preuve tangible, physique, papier, quoi. Mais notre gestionnaire peut voir le dossier informatique, et n’a donc plus besoin du dossier papier pour étudier et traiter la requête du client. Il ne va donc plus le demander aux archives. Néanmoins, une fois sa transaction effectuée, il enverra la nouvelle pièce aux archivistes, pour insertion dans le dossier.

Les bases de données

Et puis, les systèmes de gestion de fichiers informatiques se font de plus en plus sophistiqués. On voit apparaître des bases de données, où l’on peut décrire le dossier comme un vrai dossier, avec ses chemises et sous-chemises, au lieu de l’alignement informe d’un fichier séquentiel qui s’enroule sur une bande magnétique (mais sans musique)… De plus, au lieu d’alimenter cette base la nuit, on permet au gestionnaire d’y inscrire directement sa mise à jour le jour.

Et c’est là qu’apparaît le danger, de l’avis de l’informaticien, qui s’estime garant de l’intégrité des données. Il craint en particulier l’erreur de programme non détectée, qui va laisser des dizaines de gestionnaires polluer à tour de bras la base à l’insu de leur plein gré.

Il craint aussi le télescopage de mises à jour réalisées par plusieurs gestionnaires dans un même dossier. Par exemple, un changement d’adresse et un changement de RIB, qui relèvent de deux services distincts.

Le cas d’école est simple à expliquer en trois phases,

1. nos deux gestionnaires chargent en mémoire le même dossier de M. Martin, habitant à l’adresse A et ayant un compte dans la banque R,
2. le premier remplace l’adresse A par B, et valide sa mise à jour,
3. le second, interrompu par un coup de téléphone, tarde un peu, puis indique que la banque T remplace la banque R, et valide sa mise à jour.

Que se passe-t-il dans la base ?

1. lecture pour les deux, adresse A et banque R,
2. écriture (du premier), adresse B et banque R,
3. écriture (du second), adresse A et banque T.

Et vlan ! Catastrophe ! Le changement d’adresse a été oublié !

Il est des informaticiens qui, eux, n’ont pas oublié d’être intelligents. Et qui proposent des solutions fondées sur le verrouillage du dossier. Eh oui, dans le temps, le dossier papier n’avait pas le don d’ubiquité, un seul gestionnaire à la fois !

Pour cela,

1. à l’arrivée du premier gestionnaire, lecture du dossier, positionnement d’un drapeau occupé, réécriture immédiate, envoi de son image au gestionnaire (adresse A, banque R),
2. à l’arrivée du second, lecture du dossier, zut il est occupé, fin de non recevoir « ce dossier est en mains, repassez plus tard »,
3. à la validation de la transaction du premier, réécriture du dossier modifié, positionnement du drapeau libre, confirmation de la mise à jour au gestionnaire (adresse B, banque R),
4. lorsque le second gestionnaire tente à nouveau sa chance, le dossier lui est délivré (adresse B, banque R), il peut indiquer la banque T, valider, et le dossier contiendra bien en final (adresse B, banque T). CQFD.

Et ça marche ! Oui… sauf que les ordinateurs ont parfois des caprices, et craignent une grève EDF surprise, ou une panne de courant inopinée, ou encore le programmeur expérimental qui lui fait prendre les pieds dans le tapis. Si alors, tandis que notre gestionnaire tripote impunément son dossier, survient un incident grave provoquant une interruption brutale de service, que se passe-t-il ?

Notre gestionnaire ronge son frein, proférant des propos bien sentis à l’encontre du progrès, de l’informatique et des informaticiens ! L’ordinateur, lui, reprend son souffle. Les exploitants (ceux qui mettent le charbon dans la chaudière), utilisent le système de sécurité de la base de données pour la rétablir dans son état juste avant le crash. Et ils annoncent triomphalement que c’est reparti, avec le sentiment d’avoir vite et bien fait leur boulot !

Notre gestionnaire, de retour de déjeuner (il faut bien reprendre des forces), constate que « ça marche ! » et se précipite comme un forcené sur son clavier, pour constater que « ce dossier est en mains, repassez plus tard ». C’est pas vrai, ça ! Et en plus, il y en a un qui m’a pris mon tour. Déconfit, il met un post it sur le dossier et s’attaque au suivant.

Le lendemain matin, « ce dossier est en mains, repassez plus tard » ! Pas possible ! Encore la faute à l’informatique !

Eh oui, en fait, la veille, avant le plantage, le dossier avait été positionné occupé. Le dialogue ayant été interrompu, personne ne peut plus le libérer, il reste sur une voie de garage…

Bien entendu notre informaticien, agacé par toutes les demandes de passage de gomme à octets pour repositionner des drapeaux à libre, réfléchit à la conception d’une parade. On peut en citer deux,

1. on installe le drapeau occupé non pas dans le dossier, mais dans un fichier spécialement prévu à cet effet. Une fois la transaction terminée, le drapeau sera effacé dans ce fichier. En cas de crash, il suffit de vider ce fichier avant de redémarrer,
2. on conserve le principe du drapeau inscrit dans la base, mais on lui adjoint une identification du gestionnaire qui a pris le dossier en charge (souvent, on choisit le numéro de terminal, identifiant unique pour la machine, un peu comme l’adresse IP aujourd’hui). Lorsque le gestionnaire revient après plantage, on le reconnaît et on le laisse reprendre sa mise à jour. Il reste le problème d’une panne du terminal (eh oui, tout est possible, tout est réalisable !), où le gestionnaire, obligé d’aller se brancher ailleurs, ne sera pas reconnu pour ce dossier, et refoulé !

Mais les opérations d’écriture sur disque sont coûteuses en ressources machine, et il est impératif, sur un ordinateur sollicité par plusieurs centaines, voire plusieurs milliers d’utilisateurs, de faire la chasse au gaspi pour optimiser les temps de réponse.

Les dispositifs de verrouillage

On a donc demandé aux concepteurs de SGBD (systèmes de gestion de bases de données) des dispositifs logiques de verrouillage, déchargeant le développeur de ce type de contraintes. Il lui suffira d’annoncer qu’il effectue une lecture avec intention de mise à jour, et la ressource concernée lui sera réservée jusqu’à l’accomplissement de cette mise à jour.

Dans le cadre d’un SGBDR (relationnel), il est ainsi possible de locker (verrouiller) une table, ou un rang (entendez par là un fichier, un enregistrement).

Le problème, c’est l’utilisateur qui se présente en intention de mise à jour, provoque le verrouillage d’une table, et s’interrompt pour une raison [peut-être] tout à fait légitime et indépendante de sa volonté. Pendant qu’il fait autre chose, personne ne peut plus travailler avec cette table. Si elle est stratégique, à la croisée de tout le système, toute l’entreprise sera arrêtée par un amateur de café qui va s’en chercher un !

J’ai bien entendu outré le propos, mais on n’est pas à l’abri de certaines contentions de données, qu’il faudra diagnostiquer et tenter de résoudre au cas par cas, le plus souvent à chaud.

Entre temps, notre gestionnaire doit toujours penser à envoyer aux archives tous les compléments de dossier qui sont passés entre ses mains : le dossier papier reste de rigueur dans la plupart des domaines officiels.

C’est ainsi que j’ai pu, dans une Caisse de Retraite, voir se fermer le plus vieux dossier de la maison. Il était effectivement un brin poussiéreux. Pourtant, le document du dessus était encore tout chaud : c’était l’acte de décès d’une centenaire, qui mettait un terme à une longue réversion : elle avait épousé à 20 ans un vieillard de 80 ans. Le dossier qu’on refermait avait été ouvert 140 ans auparavant !

Partir gagnant

Pour éviter les problèmes de blocage logique résultant d’une sécurisation concurrentielle des données, il existe une méthode que j’appelle « Partir gagnant ».

Elle consiste à prétendre qu’il n’y a vraiment pratiquement aucune chance que deux gestionnaires attaquent en même temps le même dossier. On va donc ignorer ce risque et oublier toute prudence. Dans notre exemple, deux gestionnaires demandent en même temps le même dossier. On le leur fournit. Pas de problème, puisque ça n’arrive jamais.

Le premier, un bosseur qui ne mélange pas le travail et le plaisir, effectue son changement d’adresse avec brio et valide sa mise à jour. Le second, interrompu par sa femme au téléphone (une sombre histoire de crèche et de gamin malade), est un peu perturbé, on le comprend. Mais il prend sur lui, réalise son changement de banque et valide sa mise à jour. Et là, surprise ! « Désolé, quelqu’un a mis à jour ce dossier, veuillez reprendre la procédure ».

Un miracle ? Non. D’ailleurs, en informatique, les miracles n’existent pas, je l’affirme, c’est du vécu ! En fait, on a demandé à chaque programme chargé d’une mise à jour,

• de conserver soigneusement une image du dossier tel que fourni à la lecture, en parallèle avec son état en cours de mise à jour,
• au moment de la demande de mise à jour de la base, de relire le dossier pour vérifier qu’il est resté strictement identique à son état initial en début de transaction,
• si oui (c’était bien le cas pour le premier gestionnaire), d’entériner la mise à jour demandée,
• sinon (c’est le cas du second gestionnaire), de la refuser en émettant le message d’excuses.

On notera que l’on peut faire l’économie d’une image initiale complète. Il suffit de garder de côté la date de dernière mise à jour du dossier (timestamp), pour comparaison lors de la relecture avant mise à jour.

Certes, si l’on compte bien, on réalise deux lectures et une écriture. Mais il faut bien comprendre que la lecture initiale est libre, c’est-à-dire sans intention de mise à jour, laissant toute latitude au consommateur de café sans pénaliser ses collègues. Par ailleurs, il n’y a pas de dialogue, donc d’interruption humaine, entre la seconde lecture, avec intention de mise à jour, et l’écriture, donc l’ensemble se déroule en une infime fraction de seconde.

Il faut savoir aussi que, à cause de cas de navigation complexe dans les données au cours de la transaction, plusieurs SGBD demandent systématiquement une relecture de positionnement avant mise à jour. Cette dépense obligatoire ne peut donc plus être jugée inconsidérée…

Eh bien, en 10 ans d’expérience de cette méthode appliquée à l’ensemble de l’informatique dédiée à 500 utilisateurs gérant 3 millions de dossiers, l’incident a été relevé… une fois ! Et le plus surpris a été le chef de projet informatique, qui avait depuis longtemps désespéré qu’on lui annonce le cas.

Etonnante aussi, la réaction du gestionnaire qui a vu apparaître le message : il a trouvé la chose tout à fait normale, et sécurisante. Il a en outre deviné quel collègue l’avait doublé, et est passé le voir pour discuter du dossier !

Mais quel intérêt pour mon site ?

Si vous avez conçu un site purement descriptif, fonctionnant uniquement en consultation, il est certain que cet article ne vous concerne pas… mais ne m’en veuillez pas, vous auriez pu vous en douter au regard de son titre !

Si en revanche votre site collecte des données, il serait peut-être dommage d’en perdre certaines (par exemple, dans l’incrémentation de compteurs à l’occasion d’un sondage) du fait d’une affluence par ailleurs plutôt flatteuse !

A bon entendeur…

[cchristian]

Bonjour,

 

Bravo pour cet intéressant historique sur le thème des accès concurrents, sans excès de nostalgie, on s'y croirait ...!

 

Cordialement,

 

Christian.

[Invité Fred]

Hello,

 

Si vous avez conçu un site purement descriptif, fonctionnant uniquement en consultation, il est certain que cet article ne vous concerne pas…

 

Donc ce forum, comme n'importe quel autre forum n'est pas concerné ?

 

Suggestions / propositions :

 

1. Soit le message est copié avec les balises de code dans un champ texte non éditable au dessus du formulaire dans lequel l'on tape les messages et l'utilisateur devra copier-coller le texte depuis le champ texte non éditable vers le "textarea", cela afin d'éviter d'envoyer un mauvais message après visualisation obligatoire de où ce trouve la modification et visualisation pour voir de quelle modification il s'agit, puisque il y a eu une modification effectuée et signalée.

 

2. Soit le message est déjà présent dans le "textarea" et un captcha prévient de tout envoi précipité mais seulement après visualisation obligatoire de où ce trouve la modification et visualisation pour voir de quelle modification il s'agit, puisque il y a eu une modification effectuée et signalée.

 

3. Soit l'on regroupe les points 1 et 2, en espérant que ça ne suscite pas l'exaspération des gens suite à un nombre important d'opérations à faire = vérification des modifications obligatoire (peut-être dans des champs texte avec un surlignement rouge si le texte n'est pas déjà surligné en rouge sur la même page d'édition des messages), copié-collé et captcha.

 

pour le sujet et surtout le contenu (si .sujet!=.contenu)  et  :ciao:E.O.T : à vous lire.

[Dylav]

Salut Fred,

 

J'avoue ne pas bien saisir le sens de ton intervention, ni son rapport avec le sujet

[Invité Fred]

Hello,

 

Effectivement, si vous considérez que les mises à jours concurrentes (ou concurrentielles, c'est pareil pour moi) ne s'applique pas à un forum, j'ai peu de chance que mes propositions vous intéresses mais j'ai trouvé le sujet très intéressant, non pas en tant que programmeur pour le peu que je bidouille mais en tant qu'utilisateur espérant que chaque interface bénéficie de ces fonctions de sécurités/sauvegardes.

 

Quand l'on écrit un message en réponse dans un topic déjà existant sur un forum (et même pour un nouveau topic) et que l'on tente de l'envoyer ; avant cela l'on a pris la peine en général de lire ce qui a été écrit et l'on répond en conséquence, personnellement je fais comme cela. Maintenant, si il y eu entre tant quelqu'un qui a écrit et envoyé dans le topic un message, il serait peut-être bon que je sois informé de ce nouveau message lorsque je tente d'envoyer le mien afin de vérifier si ce que j'écris est correcte ou si il faut que je modifie ma réponse.

 

Sur wikipedia il y a ce système = si je tente d'envoyer un message ou plutôt si je tente de valider une modification et que quelqu'un a modifié quelque chose entre temps, j'ai une alerte affichée dans la page qui s'ouvre sur le même onglet et je dois vérifier les modifications qui sont automatiquement affichées et ensuite je dois modifier mon texte en conséquence quand j'ai pensé à utiliser un moyen de sauvegarde du texte car des fois ça plante et l'on perd le texte que l'on viens de taper.

 

Modèle/Base = Dans un forum ou un wiki, si une modification ou un ajout a été effectuée entre le moment où l'on clic sur répondre ou lorsque l'on change de page et lors de l'appui sur le bouton pour valider (avec un système de délai rétroactif à voir et tester en pratique = idée rapide), et bien l'on doit être informé de cette modification et le message (forum) ou le texte (wiki) que l'on a tapé doit nous être représenté pour que l'on est pas tout à retaper et que l'on puisse le modifier le cas échéant ou ne pas l'envoyer. Et pour éviter de renvoyer un texte de façon mécanique et que c'était pas ce que l'on voulait, l'on peut mettre un petit captcha (ou un truc comme sur Google Gmail Lab qui fait que l'on a dix secondes pour rappeler un courriel partie il y a moins de dix secondes, le délai étant réglable je crois de mémoire).

 

HS :"Si vous êtes manageur chez Orange/France telecom et que vous souhaitez pousser un ou une employée vers le vide merci BEAUCOUP de leur asséner régulièrement: "J'avoue ne pas bien saisir le sens de ton intervention, ni son rapport avec le sujet." ; ensuite trouvez et utilisez tout les moyens pour l'exclure et lui faire sentir que cette personne est inutile. Un ou une employée plus conciliante pour son salaire et terrorisé(e) par le chômage donc plus malléable pourra ensuite prendre ça place." :HS

 

Toujours +1 pour le sujet et 10sur10 pour le contenu : E.O.T (ouf ils sont d'accord avec moi ) : à vous lire.

 

À bon entendeur…

[Dylav]

Maintenant, s'il y a eu entre temps quelqu'un qui a écrit et envoyé dans le topic un message, il serait peut-être bon que je sois informé de ce nouveau message lorsque je tente d'envoyer le mien

Rien de plus simple. Lorsque tu mets en forme ton message, tu peux voir, en bas de ta zone de saisie, la liste inversée des dix derniers messages insérés dans le sujet, avec donc le plus récent en tête.

Si tu cliques sur le bouton [Prévisualisation], non seulement tu peux contrôler l'aspect qu'aura ton message (au-dessus de ta zone de saisie), mais tu peux également consulter la liste réactualisée des dix derniers messages. Tu détecteras ainsi l'arrivée des nouveaux messages qui auront réussi à te doubler !

[Dylav]

Précision : dans la nouvelle version d'IPB (intervenue depuis la création de ce sujet), lorsque l'on rédige un message dans un sujet existant, une pop-up nous avertit de la rédaction de nouveau(x) message(s), et nous propose de les visualiser.