Gestion Des Accées Concurrents

: Étape n°1 – l’utilisateur A lit une ligne dans un database colonne Identifiant Nom Prenom 101 DUPOND Pierre valeur initiale valeur actuelle locale 101 DUPOND Pierre valeur dans le database 101 DUPOND Pierre

Étape n°2 – l’utilisateur B lit la même ligne Étape n°3 – l’utilisateur B modifie le Prénom de « Pierre » en « Pierrot », et envoie la mise à jour au database colonne Identifiant Nom Prenom 101 DUPOND Pierre valeur initiale valeur actuelle locale 101 DUPOND Pierrot valeur dans le database 101 DUPOND Pierre

À cette étape, la mise à jour sur le serveur est possible, parce qu’à l’instant de la mise à jour, la valeur dans le database est identique à la valeur initiale du client.

Étape n°4 – l’utilisateur A modifie le Prénom de « Pierre » en « Jean », et envoie la mise à jour au database colonne Identifiant Nom Prenom 101 DUPOND Pierre valeur initiale valeur actuelle locale 101 DUPOND Jean valeur dans le database 101 DUPOND Pierrot

À cette étape, l’utilisateur A rentre dans un conflit de concurrence optimiste, parce que la valeur qu’il trouve sur le database n’est plus la valeur initiale qu’il attendait. Quelle décision prendre ?  Écraser les modifications faites par l’utilisateur B ?

Ou bien



Abandonner les modifications demandées par l’utilisateur A ?

Michel LÉVY – michel.levy@vfpmigration.fr

2

STRATAFRAME : Gestion des accès concurrentiels

Peut-on DÉSACTIVER la gestion des accès concurrents ?

Oui, on peut désactiver la gestion des accès concurrents en mettant la propriété ConcurrencyType à Off sur un Business Object. Il n’y aura alors aucune vérification d’accès concurrents. À chaque fois qu’un Business Object enregistrera ses changements dans un database, il y écrasera systématiquement les données stockées.

La désactivation de la gestion des accès concurrents est la meilleure solution dans un environnement mono-utilisateur, ou bien quand les données devront être modifiées et enregistrées par un programme automate. Un utilisateur unique ne générera jamais de conflit d’accès concurrent, et un automate ne trouvera pas d’utilisateur pour décider comment résoudre le conflit ! Dans ces conditions, vous gagnerez en rapidité et en efficacité en désactivant la gestion des accès concurrents. Mais c’est inconcevable dans un environnement multi-utilisateurs. Voici la structure de la commande UPDATE générée pour l’utilisateur 1 avec le UpdateConcurrencyType = Off

UPDATE Clients SET Nom = 'DUPONT' , Prenom = 'Jean' WHERE Identifiant = 101

Dans ce scénario, l’Utilisateur 1 va enregistrer ses modifications sur le serveur ; les modifications faites par l’Utilisateur 2 sont écrasées.

Une mise à jour de vue distante en VFP, avec le WHERETYPE réglé sur Champs Clés seulement, envoie au serveur SQL la commande suivante :

UPDATE dbo.clients SET nom = @P1 WHERE client_pk = @P2

La gestion optimiste utilisant tous les champs

Vous allez activer la gestion optimiste des accès concurrents utilisant tous les champs en définissant la propriété ConcurrencyType à OptimisticAllFields sur un Business Object. Dans ce mode optimiste, StrataFrame va ajouter une longue collection de conditions dans la clause WHERE des requêtes UPDATE et DELETE, pour vérifier que la ligne n’a pas été modifiée depuis qu’elle a été lue sur le serveur. Pour chaque champ de la table, StrataFrame ajoute 2 tests conditionnels : un pour déterminer si la valeur du champ a changé, et un autre pour vérifier si les 2 valeurs ne sont pas nulles (NULL ne pouvant pas être testé dans une égalité).

Michel LÉVY – michel.levy@vfpmigration.fr

3

STRATAFRAME : Gestion des accès concurrentiels

Voici la structure de la commande UPDATE générée pour l’utilisateur 1 avec le UpdateConcurrencyType = OptimisticAllFields

UPDATE Clients SET Nom = 'DUPONT' , Prenom = 'Jean' WHERE ( ( Nom IS NULL AND @NomInitial IS NULL ) OR ( Nom = 'DUPONT' ) ) AND ( ( Prenom IS NULL AND @PrenomInital IS NULL ) OR ( Prenom = 'Pierre' ) ) AND Identifiant = 101

Dans ce scénario, quand l’Utilisateur 1 va essayer de sauver son enregistrement à l’étape n° 4, les clauses ajoutées à sa requête vont faire échouer son UPDATE ; aucune ligne ne sera touchée. StrataFrame va instancier un objet RowNotUpdatedException, qui va stopper le process d’enregistrement. Cet objet est dérivé de la classe Exception de .Net

Une mise à jour de vue distante en VFP, avec le WHERETYPE réglé sur Champs Clés pouvant être mis à jour, envoie au serveur SQL la commande suivante :

UPDATE dbo.clients SET nom WHERE clientid AND societe AND nom AND adresse AND ville AND codepostal AND pays AND tel AND client_pk

= = = = = = = = = =

@P1 @P2 @P3 @P4 @P5 @P6 @P7 @P8 @P9 @P10

Michel LÉVY – michel.levy@vfpmigration.fr

4

STRATAFRAME : Gestion des accès concurrentiels

La gestion optimiste utilisant un champ d’horodatage

Vous pouvez également activer la gestion optimiste des accès concurrents en utilisant un champ de type TimeStamp pour l’horodatage (à condition bien entendu que la table sur le serveur comporte un champ de ce type). Sur le Business Object, il vous faut définir la propriété ConcurrencyType à OptimisticTimeStamp , mais également renseigner la propriété RowVersionOrTimeStampColumn avec le nom du champ de type TimeStamp présent dans la table. Ce champ doit être présent dans le Business Object. Les champs de type TimeStamp sont automatiquement mis à jour par le SGBDR à chaque enregistrement (sur SQL Server, ce type de champ est en fait un binaire et non pas une date-heure). Dans ce mode optimiste, StrataFrame ajoute UNE SEULE condition à la clause WHERE de la commande UPDATE ou DELETE, pour vérifier si la ligne a été modifiée sur le serveur.

Voici la structure de la commande UPDATE générée pour l’utilisateur 1 avec le UpdateConcurrencyType = OptimisticTimeStamp

UPDATE Clients SET Nom Prenom WHERE TimestampColumn AND Identifiant

= = = =

'DUPONT' , 'Jean' @TimestampValue 101

Dans ce scénario, quand l’Utilisateur 1 va essayer de sauver son enregistrement à l’étape n° 4, le test d’horodatage va échouer : quand l’Utilisateur 2 a enregistré sa ligne à l’étape n°3, la valeur du champ de type TimeStamp a été automatiquement modifiée. L’UPDATE de l’Utilisateur 1 va échouer ; aucune ligne ne sera touchée. StrataFrame va instancier un objet RowNotUpdatedException, qui va stopper le process d’enregistrement.

Une mise à jour de vue distante en VFP, avec le WHERETYPE réglé sur Champs Clés et Horodateur, envoie au serveur SQL la commande suivante :

UPDATE dbo.clients SET nom = @P1 WHERE client_pk = @P2 AND colTimeStamp = @P3

Michel LÉVY – michel.levy@vfpmigration.fr

5

STRATAFRAME : Gestion des accès concurrentiels

La gestion optimiste utilisant un champ de versionning

Ce mode de gestion optimiste des accès concurrents fonctionne comme le précédent, mais s’appuie sur une colonne de type Integer pour enregistrer le changement de version (votre table doit contenir un champ de ce type dédié à cet usage). Sur le Business Object, il vous faut définir la propriété ConcurrencyType à OptimisticRowVersion , mais également renseigner la propriété RowVersionOrTimeStampColumn avec le nom du champ de type Integer choisi pour cet usage. Ce champ doit être présent dans le Business Object.

Attention ! Ce champ n’est pas automatiquement mis à jour, c’est à vous de le faire ! Dans ce mode optimiste, StrataFrame ajoute UNE SEULE condition à la clause WHERE de la commande UPDATE ou DELETE, pour vérifier si la ligne a été modifiée sur le serveur. Les exemples de commandes UPDATE indiqués ci-dessus ne montrent que la structure de la commande ; en réalité, toutes ces commandes sont générées sous forme de requêtes paramétrées. Ces requêtes paramétrées sont identiques aux procédures stockées générées par DDT.

Vous pouvez visualiser et étudier les requêtes que StrataFrame envoie au serveur SQL en incluant dans votre code cette ligne :

DataBasics.DataSources("").SetDebugOn( _ My.Computer.FileSystem.SpecialDirectories.Desktop & _ "\SFdebugData.html",