[Généralités] Base multi utilisateurs, accès exclusif à un enregistrement

[SomeoneElseIsHere]

Bonjour à tous

En quelques mots, voici mon besoin :

J'ai une table contenant une liste de tâches "à traiter".
J'ai une 20aine d'utilisateurs accèdant simultanément à cette liste et devant traiter l'ensemble des tâches.
Chaque utilisateur ne doit traiter qu'une tâche à la fois.
Une même tâche ne doit pas être traitée simultanément par plusieurs utilisateurs.
Une tâche une fois traitée va, soit être marquée comme "effectuée" et ne sera donc plus accessible aux utilisateurs, soit être marquée comme "à retraiter" ultérieurement.
Une tâche marquée comme "à retraiter" doit l'être après que l'ensemble des tâches "à traiter" soient traitées

Pour donner une image qui parlera à tout le monde, imaginez un tas de papier à traiter.
Chaque utilisateur prend le premier papier, celui en haut de la pile, et le traite.
En fonction des règles métiers en vigueur, soit il le classe, soit il le met sous la pile afin qu'il soit retraité ultérieurement.
Cela jusqu'à ce que l'ensemble des papiers soient classés.

Je n'ai aucune idée de la méthode à utiliser pour arriver à mes fins ... si une bonne âme pouvait me donner un coup de main !
A ce stade de la réflexion, je n'ai pas ou peu de contraintes sur la structure de la table devant accueillir les données.

[wimbish]

Bonjour,
Utilise le blocage d'enregistrement : Fonction Hbloque() ou les option des fonction Hlit.

Pour chaque utilisateur qui tente de lire un enregistrement, tu vérifie que ce dernier n'est pas bloqué (donc traité par quelqu'un d'autre)

[Nicolas_Jeanneau]

Bonjour,

en fait imagines ta table papier, tu mets 2 colonnes de plus que les données : Traitee, AReTraiter.
Tu fais une requête sur les lignes qui ont une valeur 0 dans les 2 colonnes.

Si tu as des lignes, tu les affiches.

Si tu n'en as pas, tu fais une 2e requête avec colonne AReTraiter = 1.

Si tu n'en as pas, aucun papier dans la pile !

Il faudra gèrer un timer qui te permet de rafraichir le tableau de papiers en attente si l'écran est affiché depuis longtemps et que le rythme de remplissage est assez rapide.

à bientôt et bon courage,

Nicolas

[SomeoneElseIsHere]

Envoyé par wimbish

Bonjour,
Utilise le blocage d'enregistrement : Fonction Hbloque() ou les option des fonction Hlit.

Pour chaque utilisateur qui tente de lire un enregistrement, tu vérifie que ce dernier n'est pas bloqué (donc traité par quelqu'un d'autre)

Merci pour ta réponse !

Donc l'idée serait de procéder comme suit :

- Créer une table des tâches à effectuer comprenant un champs utilisateur & une date de traitement.

- A chaque demande d'un utilisateur, lui mettre à disposition le premier enregistrement ayant la plus petite date de traitement et n'étant pas affecté à un utilisateur

- Affecter à l'utilisateur la tâche ainsi retournée tout en la bloquant en lecture/ecriture

- En fin de traitement, supprimer l'affectation de la tâche à l'utilisateur et soit de modifier la date de traitement à la date/heure/microseconde actuelle (ce qui aura pour effet de le faire passer après les autres, plus anciens) soit le supprimer de la table

Est ce que le procédé semble correct ?

[SomeoneElseIsHere]

Envoyé par Nicolas_Jeanneau

Bonjour,

en fait imagines ta table papier, tu mets 2 colonnes de plus que les données : Traitee, AReTraiter.
Tu fais une requête sur les lignes qui ont une valeur 0 dans les 2 colonnes.

Si tu as des lignes, tu les affiches.

Si tu n'en as pas, tu fais une 2e requête avec colonne AReTraiter = 1.

Si tu n'en as pas, aucun papier dans la pile !

Il faudra gèrer un timer qui te permet de rafraichir le tableau de papiers en attente si l'écran est affiché depuis longtemps et que le rythme de remplissage est assez rapide.

à bientôt et bon courage,

Nicolas

Merci pour ta réponse. S'agissant de la gestion des ficher à traiter et/ou à retraiter, je n'ai pas trop de soucis et je pense que mon idée de poser ula date de traitement sur chaque fiche (cf mon post ci dessus) doit répondre au besoin.
C'est surtout la gestion de l'accès exclusif et de la selection de la tâche qui me pose problème...

[wimbish]

Ta méthode me semble bonne.
Attention cependant, si tu sélectionne l'enregistrement ayant la plus petite date de traitement, les dates vides serons traitées en premier (ok) mais quand toutes aurons été traitées, tu retraiteras des taches déjà traitées.
Je te conseil donc de ne rechercher que les enregistrements ayant des dates vides.

[SomeoneElseIsHere]

Envoyé par wimbish

Ta méthode me semble bonne.
Attention cependant, si tu sélectionne l'enregistrement ayant la plus petite date de traitement, les dates vides serons traitées en premier (ok) mais quand toutes aurons été traitées, tu retraiteras des taches déjà traitées.
Je te conseil donc de ne rechercher que les enregistrements ayant des dates vides.

Oui, c'est exactement ce que je souhaites !
Tant qu'une tâche n'est pas classée (cad supprimée en somme), elle reste à traiter ... cf mon exemple de la pile de papier

Donc je valide le procédé, il faut maintenant que je trouve comment faire cela proprement sous windev, et ça c'est pas gagné, je ne maitrise que peu le bouzin

[SomeoneElseIsHere]

D'ailleurs, sous Windev avec une base hyperfile classic, quelle est la meilleure méthode pour selectionner l'enregistrement d'une table correspondant aux deux critères cités plus haut (plus petite date de traitement, ou null le cas écdhéant, et pas affecté à un utilisateur), tout en le bloquant en lecture/ecriture ?
En sql, c'est simple comme bonjour, mais je seche un peu avec les hlitrecherche, hlitrecherchepremier et tutti quanti ...

[Nicolas_Jeanneau]

je ferais un test sur l'ID d'enregistrement pour trouver le plus petit et donc le plus ancien. Ensuite tu fais une requête pas un hlitrecherche, c'est nettement plus simple.

[SomeoneElseIsHere]

Envoyé par Nicolas_Jeanneau

je ferais un test sur l'ID d'enregistrement pour trouver le plus petit et donc le plus ancien. Ensuite tu fais une requête pas un hlitrecherche, c'est nettement plus simple.

Sur l'ID ca marche pas dans le cas d'une tâche à retraiter : son ID sera plus petit que d'autres tâches, mais il devra être retraité après.

Mais en revanche je peux adapter ta proposition à la date de traitement, ainsi si je comprends bien :
1/ je cherche le 1er dossier ayant la plus petite date de traitement (si aucun n'a encore été traité, il me sort la 1ere ligne avec une date nulle)
2/ je vérifie qu'il n'est pas affecté à un autre utilisateur
3/ je l'affecte à l'utilisateur qui vient d'en faire la demande, tout en le bloquant en lecture/ecriture.

Cela étant, dans ce procédé, je redoute les accès concurrents et le risque d'affecter en simultané une même tâche à 2 utilisateurs ...

y'a pas moyen de faire tout cela en une seule requête ?

Ou alors il faut utiliser des transactions ?

[Nicolas_Jeanneau]

Si c'est l'utilisateur qui prend une tâche, la question de blocage devrait se faire toute seule si tu utilises la fonction Hbloque.

Concernant la recherche, je ferais un tri sur Date,ID en effet.

[SomeoneElseIsHere]

Envoyé par Nicolas_Jeanneau

Si c'est l'utilisateur qui prend une tâche, la question de blocage devrait se faire toute seule si tu utilises la fonction Hbloque.

Concernant la recherche, je ferais un tri sur Date,ID en effet.

Donc :
1/ on cherche un enregistrement ayant la plus petite date de traitement
2/ on vérifie qu'il n'est pas affecté à un autre utilisateur
3/ on le bloque et on l'affecte à l'utilisateur

C'est bien ça ?

Mais alors, durant les étapes 1/ et 2/ on risque bien des accès concurrents avec 2 utilisateurs pointant sur le même enregistrement ?
Comment tu palies ce risque ?

[wimbish]

Bonjour,
C'est ta fonction de lecture qui doit gérer le blocage.
SI HLit(LeFichier,hNumEnrEnCours,hBlocageLectureEcriture) ALORS
//Traitement et l'enregistrement devient bloqué
SINON
// l'enregistrement est déjà bloqué, il faut en lire un autre.
FIN

[SomeoneElseIsHere]

Envoyé par wimbish

Bonjour,
C'est ta fonction de lecture qui doit gérer le blocage.
SI HLit(LeFichier,hNumEnrEnCours,hBlocageLectureEcriture) ALORS
//Traitement et l'enregistrement devient bloqué
SINON
// l'enregistrement est déjà bloqué, il faut en lire un autre.
FIN

Parfait ! je suis passé à côté de la smiplicité et n'ai pas vu que tout pouvait être géré par cette fonction ...

Question complémentaire : quel est l'interet de gerer l'enregistrement bloqué ? puisqu'il est bloqué, il n'est pas accessible, donc Windev va nous positionner sur le suivant automatiqeument non ?


Merci à vous pour votre aide (et patience !)

[Nicolas_Jeanneau]

ah non il ne fait pas ça ! Il t'indique que tu ne peux pas le modifier car il est bloquer, que tu peux parfois pas le lire non plus etc ...

Pour passer au suivant, il faut utiliser les fonctions H.

[SomeoneElseIsHere]

Bon, après quelques galères sur la gestion des enregistrements bloqués, voila où j'en suis :

HSurErreur("Campagnes_Dossiers", hErrBlocage, "CampagneDossierSuivant")
HLitPremier(Campagnes_Dossiers,DateIntegration,hBlocageLectureEcriture)

traitement à effectuer par l'utilisateur

Campagnes_Dossiers.DateIntegration = DateSys() + HeureSys()
HModifie(Campagnes_Dossiers,hNumEnrEnCours)

La procédure de gestion des erreurs étant :

PROCEDURE CampagneDossierSuivant()

HLitSuivant(Campagnes_Dossiers,DateIntegration,hBlocageLectureEcriture)

Après quelques tests en multi utilisateurs, cela semble fonctionner.

Vous en pensez quoi ?

[SomeoneElseIsHere]

Bon, j'ai crié victoire trop vite. Cela fonctionne en mode multi utilisateurs ....aléatoirement !

Après de multiples essais, j'en suis là :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
HSurErreur(Campagnes_Dossiers,hErrBlocage,"")

HLitPremier(Campagnes_Dossiers,DateIntegration,hBlocageLectureEcriture)

TANTQUE HEnDehors()
	HLitSuivant(Campagnes_Dossiers,DateIntegration,hBlocageLectureEcriture)
FIN

Traitement de la tâche par l'utilisateur

Campagnes_Dossiers.DateIntegration = DateSys() + HeureSys()
HModifie(Campagnes_Dossiers,hNumEnrEnCours,hBlocageLectureEcriture)

Je test avec plusieurs interfaces ouvertes en appelant une tâche alternativement de l'une puis de l'autre, et inévitablement cela finit par planter avec le message suivant :

Erreur à la ligne 6 du traitement Clic sur BTN_Bouton3.
Vous avez appelé la fonction HLitSuivant.
Une erreur de blocage est survenue sur la fonction 'HLitPremier' précédente et n'a pas été traitée.
Fonction appelée à la ligne 3 du traitement 'Clic sur BTN_Bouton3'.

Je comprends bien le message mais je ne vois pas quoi modifier pour que cela ne se reproduise pas ...

[wimbish]

Bonjour,
la procédure appelée par fonction HsurErreur doit renvoyer une constante (cf Aide)

[SomeoneElseIsHere]

Envoyé par wimbish

Bonjour,
la procédure appelée par fonction HsurErreur doit renvoyer une constante (cf Aide)

oui, j'ai testé avec opAnnuler, même résultat...

[Nicolas_Jeanneau]

Si tu es passé avec une boucle Tantque il te faut tester le retour de HerreurBlocage en même temps que Hendehors :

Code :

1
2
3
Tantque pas hendehors(Campagnes_Dossiers) et HErreurBlocage(Campagnes_Dossiers)
     hlitsuivant(Campagnes_Dossiers, DateIntegration, hBlocageLectureEcriture)
FIN

à voir