Oui mais on fait quoi entre le SELECT FOR UPDATE et l'UPDATE ?Envoyé par ruthene
Si on fait rien de significatif ça ne sert à rien ...
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Oui mais on fait quoi entre le SELECT FOR UPDATE et l'UPDATE ?
Si on fait rien de significatif ça ne sert à rien ...
Bonsoir,
Afin d'entretenir un peu cette discussion je vous propose une réflexion sur ce que je pense être un résumé du problème posé pa "Mousquetaires" et qui illustre une facettte du développement tel que je le perçois et tel que je l'ai pratiqué.
Donc critiquable et certainement à critiquer !
Rappel :
L 'un des soucis majeurs qui se pose dans tout développement d'applications transactionnelles est celui de l'optimisation des ressources et des transmissions. Ceci afin de minimiser les coûts d'exploitation et de préserver l'efficacité du système. Efficacité dont l'illustrationn finale, outre les considérations de fiabilité, se ramène en schématisant à peine, à des temps de réponse satisfaisants c'est-à-dire < 3 secondes. (couple Question/Réponse)
COUPLE QUESTION/REPONSE :
Afin de satisfaire à ces exigeances les programmes TP (CICS,..) doivent dés la phase d'étude/élaboration, être élaborés de manière à assurer, de par leur logique d'exécution, une continuité entre les différents échanges homme/machine :
Question formalisée par l'utilisateur à son clavier/terminal pressant une touche de fonction ce qui engendre un message expédié au site central. Lequel renvoie via CICS (BMS) une Réponse (Un message de confirmation (ou d'anomalie) par exemple et entre autres)
Et cela, en monopolisant le moins de ressources (mémoire) possible du site central.
Ces échanges assurent à l'utilisateur un enchaînement des différentes fonctions qui s'illustrent par l'affichage sur le terminal des écrans (MAP) nécessaires à la réalisation d'une tâche administrative (Création, Modification, Annulation, Consultation d'une entité administrative/fonctionnelle telle une commande avec son en-tête et ses n lignes).
PSEUDO-CONVERSATIONNEL :
De manière schèmatique, à un couple Question/Réponse correspond le chargement du programme CICS, son exécution, suivie de sa libération de la mémoire centrale. Les données néccessaires à la poursuite de la session de travail utilisateur (prochain couple Question/Réponse) ont été (heureusement) sauvegardées dans un fichier temporaire (Temporary Storage).
ELLES PERMETTRONT LA MISE A JOUR DU (DES) FICHIER(S) APPLICATIF(S) (hormis pour le cas Consultation bien sûr).
CONTROLES ASSURANT L'INTEGRITE DES DONNEES
Et c'est ici qu'intervient une distinction entre ce que j'appelle les contrôles d'exclusivité (gérés par le SGBD) ET les contrôles d'accès concurrents (gérés par programme). Ils n'interviennent pas au même moment (au même niveau) au cours de la réalisation d'une session de travail (ensembles de couples Question/Réponse)
CENTRALISATION DES MISES A JOUR DES FICHIERS.
En effet dans un pgm TP toute mise à jour de l'ensemble des "enregistrements" constituant une entité administrative/fonctionnelle DOIT ËTRE centralisée (séquence d'instructions, éventuellement inscrites dans une itération, assurant la mise à jour de l'intégralité de l'entité fonctionnelle finalisée). Cette séquence est activée en fin de session par une action spécifique de l'utilisateur à son clavier (ex touche de fonction PF3 = validation).
Cette organisation permet, entre autres avantages, de bénéficier des mécanismes de "logging" actifs et ainsi en cas d'incident de ne pas se retrouver avec des "entités" non finalisées (une en-tête sans (toutes ses) lignes par exemple).
Mais elle permet également au programme de contrôler les mécanismes de "verrouillage" et de "déverrouillage" des "enregistrements" à mettre à jour.
PSEUDO CONVERSATIONNEL = LIBERATION DES RESSOURCES "SYSTEMES" ENTRE DEUX COUPLES QUESTION/REPONSE :
Aprés chaque "exécution unitaire" d'un pgm CICS "monté" en pseudo-conversationnel, les ressources sont libérées y compris les éventuels contrôles d'exclusivité. C'est en tout cas souhaitable car imaginons un verrouillage sur une ou plusieurs lignes d'une table DB2, intervenant nécessairement en début de session utilisateur, qui ne sera levé qu'en fin de session de travail. Si celle-ci dure 30 s c'est déjà grâve mais elle peut durer une ou plusieurs heures ..........(un utilisateur peut être détourné de sa tâche en cours pour une infinité de raisons).
A extrapoler en considérant n transactions CICS actives à un instant donné!
MAINTIEN DES RESSOURCES "APPLICATIVES" DURANT TOUTE LA DUREE DE LA SESSION UTILISATEUR.
Par contre l'entité fonctionnelle sur laquelle l'utilisateur travaille, ELLE, doit être protégée le plus tôt possible c'est à dire en début de session, où plus exactement dés la saisie/transmission par l'utilisateur de son identifiant (sa clef). Ceci afin d'empêcher tout autre intervention sur cet entité. Elle ne sera libérée par le pgm CICS qu'en fin de session utilisateur,( ainsi que la TS et les données applicatives qu'elle contient, lesquelles ont permis la centralisation de la mise à jour du des fichier(s)).
PROTECTION DES ENTITES FONCTIONNELLES
La protection des entités fonctionnelles est assurée par chaque pgm CICS et une ressource fichier dédiée à cet usage.
Chaque pgm doit vérifier si la nouvelle session qu'il administre, (dont l'identifiant de l'entité fonctionnelle vient d'être saisi et transmis par l'utilisateur ), ne se propose pas d'intervenir sur une "entité administrative" pour laquelle un "enregistrement" de clef primaire = à cet identifiant serait déjà présent dans le fichier dédié.
Si tel est le cas le pgm transmet un message à l'utilisateur lui notifiant l'impossibilté d'intervenir pour le moment, sur cette entité fonctionnelle.
Dans le cas contraire un "verrouillage pour mise à jour" est activé sur le fichier et l"enregistrement" de clé primaire = identifiant de l'entité est créé. Il sera éliminé du fichier lorsque l'utilisateur décidera de finaliser son travail.
TABLE DB2 DE SERVICE en question :
La table de service doit vraisemblablement permettre le stockage temporaire des identifiants des "entités administratives/données" sur lesquelles interviennent des utilisateurs qui ont ouvert les sessions de travail correspondantes.
Ce que je ne comprends pas très bien c'est la raison pour laquelle les contrôles s'effectuent au niveau des données d'une même entité administrative ? Cela multiplie les lignes dans la table. C'est d'ailleurs ce qui génère, ou contribue à générer le -911.
En espérant que la longueur de ce texte ne vous découragera pas,
Cordialement,
Dernière modification par Christianchristian ; 11/06/2006 à 00h28.
Le principe: on enregistre dans le record le timestamp lors de l'update. Donc quand tu écris un record, tu peux relire le timestamp dans le fichier et le comparer à celui lu lors dur select initiale. S'il diffère c'est qu'une mise à jour à eu lieu entre les deux.
Bonjour,
Merci pour cette information jab, je ne connaissais pas cette technique.
Par contre, ce que je ne perçois pas très bien c'est l'action à mener lorsque les timestamp sont différents.
Pour la transaction qui fait ce constat, il semble qu'il soit trop tard, l'évènement est consommé.
Cordialement,
ET non justement. Il te reste différents actions possibles.
Tu peux annuler l'opération en cours par un rollback et avertir l'utilisateur de l'échec de la transaction.
Tu peux aussi avant de faire l'update vérifier le timestamp et s'il diffère vérifier les champs par rapport au données de départ (qu'il faut avoir conservées) Si les champs modifiées sont différents tu fais un genre de merge en ne mettant à jour que ce qui doit. En résumé tu passe du record locking au field locking.
Ce genre de traitement est plus adapté à l'interactif qu'au traitement par lot.
D'accord pour la deuxième action, elle permet de gagner en finesse au niveau des mises à jour et permet également de préciser certains contrôles grâce à la comparaison possible entre les données initiales et celles saisies (contrôles du type : demande de mise à jour sans aucune modification effectuée ou bien tel champ déjà renseigné doit être modifié......).
Et puis surtout elle évite la base de données de service.
Mais en ce qui concerne la première action je ne suis pas d'accord, sauf peut-être pour des sessions de travail utilisateur de courte durée (très très peu de saisie) et encore ! Il est très pénalisant et déroutant pour une personne ayant passé plusieurs minutes, ou souvent davantage, à la saisie/modification de données (et à l'investigation qu'il lui faut quelquefois mener sur certaines d'entre elles), de voir tout son travail perdu pour une raison qu'elle ne maîtrise pas.
Cordialement,
Dernière modification par Christianchristian ; 12/06/2006 à 22h10.
Tout à fait d'accord avec toi mais c'est pourtant utilisé. Plutôt je pense (j'espère) dans un contexte ou les risques sont faibles grace au contexte business.
Bonsoir,
C'est vrai que l'on voit quelquefois des drôles de trucs en développement (TP).
______________________________________________________
Dans les grandes lignes, il a été possible de reconstituer les causes du -911 posé par "Mousquetaires".
Ce serait intéressant et formateur de recueillir différents avis sur ce problème particulier afin de tenter de davantage préciser, sur le plan technique et peut-être fonctionnel, les causes précises ou vraisemblables de l'incident (quelques lignes peuvent suffir). Par exemple en dégageant des scénarios plausibles à partir de la structure de la table de service, de sa clé primaire, du contexte mise à jour en TP, plus particulièrement lors de la suppression des lignes en fin de session de travail utilisateur.....
Aurais-tu une ou plusieurs idées ?
C'est une proposition un peu intéressée, car j'ai besion de me remettre dans le bain.
Cordialement,
Une variante peu coûteuse consiste à envoyer au poste local le TIMESTAMP lu avant l'affichage et ceci dans un contexte caché (même les terminaux passifs savaient gérer, alors le PC ...). Au retour la ligne à modifier est d'abord lue (et là le SELECT FOR UPDATE est indispensable) et le TIMESTAMP sauvegardé au local et renvoyé au central est comparé au TIMESTAMP qui vient d'être lu. Si les deux sont identique, alors c'est OK sinon on repart sur le poste local avec un message du genre "entité modifiée entre temps ...".
Il faut bien entendu faire la comparaison des TIMESTAMP avant toute modification des données.
Certes je peux le concevoir mais il est très pénalisant aussi d'avoir dans le SI des données incohérentes d'un point de vue fonctionnel.
De toute façon, j'ai rarement vu au cours de ma carrière des projets qui traitaient cette problématique ou même qui l'avait envisagée. Aprés c'est un choix fonctionnel ou une question de probabilités. Mais deux agents qui travaillent sur le même dossier ça peut donner des résultats curieux et le client final est rarement satisfait ...
Bonsoir,
Oui certes, j'avais bien compris !
Il fallait entendre par : l'événement est consommé :
L'état d'avancement de la session de travail utilisateur est tel, (elle est, à ce stade, en cours de finalisation) qu'il est un peu trop tard pour signaler à l'utilisateur l'impossibilité de prendre en compte son travail.
Ce à quoi Jab m'a fait deux réponses dont l'une n'a pas emporté mon adhésion ce qui a motivé votre troisième remarque et l'autre à répondu à mon interrogation ainsi formulée : Par contre, ce que je ne perçois pas très bien .......il semble qu'il soit rop tard............:
C'est précisément pour ne pas avoir de données incohérentes (voir ci-dessus) ET ne pas risquer de pénaliser les utilisateurs qu'il convient d'éviter cette méthode.
La fréquence à laquelle cet événement est susceptible d'intervenir n'a que peu d'importance car ce n'est pas plus compliqué de monter un (squelette applicatif de) pgm CICS qui tient compte des 2 règles enoncées ci-dessus.
Cordialement,
Dernière modification par Christianchristian ; 13/06/2006 à 02h10.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager