Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1677 connectés 

  FORUM HardWare.fr
  Programmation
  C#/.NET managed

  [Résolu] Comment gérer les accès concurents ?

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[Résolu] Comment gérer les accès concurents ?

n°1653949
pot2yaourt
Posté le 06-12-2007 à 16:26:12  profilanswer
 

Salut tlm !
 
J'aurais aimé savoir quelles sont les méthodes qui sont employées pour gérer les accès concurent à une base de données.  
 
Imaginons que nous avons une base avec, entre autres, une table contenant une liste de fournisseurs d'une entreprise.  
L'application cliente utilisée est de type WinForm, les données fournisseurs sont affichées dans un DataGrid et l'appli est utilisée par plusieurs secrétaires à la fois.  
Comment cela se passe-t-il lorsqu'une secrétaire met à jour les coordonnées du fournisseur X alors qu'une autre secrétaire venait tout juste de les mettre à jour qqs secondes auparavant ?
 
Cas concret :
- le fournisseur X à le numéro de téléphone suivant : 01.23.45.67.89
- les secrétaires ouvrent chacune leur application et demande la liste des fournisseurs
- la secrétaire A modifie le numéro de téléphone en : 01.22.33.44.55 et enregistre ses modifications
- la secrétaire B (qui voit tjrs le n° 01.23.45.67.89) modifie le numéro de téléphone en : 01.66.77.88.99 et enregistre ses modifications
 
Résultat, toutes les modifications effectuées par la secrétaire A sont perdues !  
 
Voilà, si vous avez des idées ou des infos sur le sujet, je suis preneur !
Merci d'avance.
 
Crdlt,
Lionel.


Message édité par pot2yaourt le 06-12-2007 à 21:54:13
mood
Publicité
Posté le 06-12-2007 à 16:26:12  profilanswer
 

n°1654000
ixemul
Nan mais sans blague ! ⚡
Posté le 06-12-2007 à 16:54:36  profilanswer
 

Il faut simplement demander aux secretaires d'arreter la coke afin d'eviter de mettre un n° de téléphone différent pour le même fournisseur.


---------------
VA APPRENDRE ET REVIENS QUAND TU SAIS, SINON ABSTIENT TOI C'EST UN GRAND CONSEIL QUE JE TE DONNE... TU ES INCOMPÉTENT ET C'EST UNE RÉALITÉ, TU N'AS RIEN A FAIRE ICI FAUT S'Y CONNAITRE ... -Jojo1998 - RIP - http://tinyurl.com/qc47ftk
n°1654042
pot2yaourt
Posté le 06-12-2007 à 17:46:14  profilanswer
 

ixemul a écrit :

Il faut simplement demander aux secretaires d'arreter la coke afin d'eviter de mettre un n° de téléphone différent pour le même fournisseur.


 
Euh.. c'est une solution que je n'avais pas encore envisagée !  :(  
 
Je vais en parler à mon chef, je suis sûr qu'il va être d'accord ! LOL !  :D  

n°1654105
moi23372
Posté le 06-12-2007 à 19:35:31  profilanswer
 

tu n'as pas vraiment de possibilités.  
 
Soit, tu vérifies avant sauvegarde si les données n'ont pas été modifiée
Soit, tu lock l'enregistrement à la lecture, mais la ça reste pourri

n°1654148
Elmoricq
Modérateur
Posté le 06-12-2007 à 21:07:56  profilanswer
 

Plutôt que de verrouiller à la lecture, je préfère proposer le formulaire en lecture seule, avec un bouton pour passer en mode écriture, qui verrouille l'enregistrement lorsqu'il est activé, jusqu'à la sauvegarde.
 
Plusieurs avantages :
- tout le monde peut consulter à la cool le même enregistrement
- une seule personne peut le modifier à un instant t
- un rafraîchissement des enregistrements au moment du verrouillage permet de s'assurer qu'on bosse sur un enregistrement à jour
- on peut beaucoup plus facilement gérer, si besoin, les droits des utilisateurs (lecture seule, lecture/écriture, admin, ...)
- tu es certain de n'avoir qu'une modification à la fois, donc c't'un peu plus facile pour gérer l'historique
 
Désavantage :  
- faut probablement repenser les formulaires, si l'application est conséquente ça risque de coûter cher
- faut gérer le cas de l'utilisateur qui verrouille un enregistrement avant de partir en week-end (expiration du verrou)

n°1654171
pot2yaourt
Posté le 06-12-2007 à 21:53:28  profilanswer
 

Excellent ! Très bonne idée !
 
En plus c'est faisable très facilement (en tous cas sur l'application sur laquelle je bosse actuellement), ça ne me demandera pas trop de boulot.
 
Merci bcp pour ta réponse !  
Tu m'enlèves un grosse épine du pied, c'est mon chef qui va être content ! LOL ! :D
 
Lionel.

n°1654875
moi23372
Posté le 08-12-2007 à 11:26:37  profilanswer
 

personnellement je ne suis pas fan de cette solution.  
Bonjour le syndrome de la tasse de café.  
 
Je pense que mettre en place une lecture avant mise à jour est nettement plus avantageuse et évite ce syndrome. Mais c'est clair qu'il faut prévoir la hashkey par exemple pour faire la comparaison dans tout les enregistrements.

n°1654920
MagicBuzz
Posté le 08-12-2007 à 13:22:36  profilanswer
 

Elmoricq a écrit :

Plutôt que de verrouiller à la lecture, je préfère proposer le formulaire en lecture seule, avec un bouton pour passer en mode écriture, qui verrouille l'enregistrement lorsqu'il est activé, jusqu'à la sauvegarde.


Je travaille sur un ERP nommé Générix, et c'est ce fonctionnement qui est utilisé effectivement.
Pour les données liées, ça peut parfois poser problème par contre, on peut avoir des dead locks, il faut prévoir des locks sur toutes les tables liées, et un "cockpit" permettant de savoir qui lock quoi...
 
Le nombre de fois qu'on m'appelle parcequ'une fiche est lockée à cause d'une conne partie en pause café en laissant une fiche ouverte en modification sur son post... C'est effarant !

n°1654922
MagicBuzz
Posté le 08-12-2007 à 13:26:07  profilanswer
 

moi23372 a écrit :

personnellement je ne suis pas fan de cette solution.  
Bonjour le syndrome de la tasse de café.  
 
Je pense que mettre en place une lecture avant mise à jour est nettement plus avantageuse et évite ce syndrome. Mais c'est clair qu'il faut prévoir la hashkey par exemple pour faire la comparaison dans tout les enregistrements.


Pas fan, c'est chiant pour l'utilisateur : je modifie une fiche pendant 10 minutes, et au moment de valider, je perds tout parcequ'un con est venu faire une bidouille rapide sur ma fiche... Très gonflant.
 
Je suispartisant du lock, en imposant des règles :
- Logiciel : Lock en écriture uniquement, sauf pour les données sensibles (fiche de stock d'un produit par exemple, si une personne a ouvert en modification, on a un fort risque que le produit ne soit plus disponible à la fin de la modif, donc la saisie d'une commande sur ce produit doit impérativement être mise en attente)
- Procédure : Chaque personne gère un portefeuil de fiches, et autant que possible, ne vient pas jouer avec les fiches des autres employés

n°1655065
moi23372
Posté le 08-12-2007 à 21:15:31  profilanswer
 

MagicBuzz a écrit :


Pas fan, c'est chiant pour l'utilisateur : je modifie une fiche pendant 10 minutes, et au moment de valider, je perds tout parcequ'un con est venu faire une bidouille rapide sur ma fiche... Très gonflant.
 
Je suispartisant du lock, en imposant des règles :
- Logiciel : Lock en écriture uniquement, sauf pour les données sensibles (fiche de stock d'un produit par exemple, si une personne a ouvert en modification, on a un fort risque que le produit ne soit plus disponible à la fin de la modif, donc la saisie d'une commande sur ce produit doit impérativement être mise en attente)
- Procédure : Chaque personne gère un portefeuil de fiches, et autant que possible, ne vient pas jouer avec les fiches des autres employés


 
Pas forcement, si l'utilisateur modifie une fiche pendant 10 minutes. Il essaye de sauvegarder, le système lui propose alors d'écraser ou d'annuler, à lui de faire son choix.  

mood
Publicité
Posté le 08-12-2007 à 21:15:31  profilanswer
 

n°1655091
MagicBuzz
Posté le 08-12-2007 à 22:46:33  profilanswer
 

Ouais, mais si les infos sont réellement en conflit avec la modif déjà effectiée, il n'a pas d'autre choix que d'annuler.
 
De plus, c'est mal de pouvoir écraser ce qu'à fait l'autre, parceque du coup il ne sait pas que ça modif a été annulée, ce qui peut rapidement impliqué des problèmes de gestion (bon, après c'est au personnel de communiquer aussi ;))

n°1655664
ixemul
Nan mais sans blague ! ⚡
Posté le 10-12-2007 à 10:34:33  profilanswer
 

le mieux reste de loguer les transactions... afin de savoir qui à fait la modif en dernier [:rhetorie du chaos]


---------------
VA APPRENDRE ET REVIENS QUAND TU SAIS, SINON ABSTIENT TOI C'EST UN GRAND CONSEIL QUE JE TE DONNE... TU ES INCOMPÉTENT ET C'EST UNE RÉALITÉ, TU N'AS RIEN A FAIRE ICI FAUT S'Y CONNAITRE ... -Jojo1998 - RIP - http://tinyurl.com/qc47ftk
n°1655711
Elmoricq
Modérateur
Posté le 10-12-2007 à 11:11:12  profilanswer
 

De toute façon un historique me semble nécessaire, pas forcément pour fliquer, mais sur des données sensibles (je bosse dans la finance), c'est important de connaître ce qui a été modifié sur une entrée.

n°1683460
yannick_fr​ere
Posté le 07-02-2008 à 17:43:34  profilanswer
 

Elmoricq a écrit :

Plutôt que de verrouiller à la lecture, je préfère proposer le formulaire en lecture seule, avec un bouton pour passer en mode écriture, qui verrouille l'enregistrement lorsqu'il est activé, jusqu'à la sauvegarde.
 
Plusieurs avantages :
- tout le monde peut consulter à la cool le même enregistrement
- une seule personne peut le modifier à un instant t
- un rafraîchissement des enregistrements au moment du verrouillage permet de s'assurer qu'on bosse sur un enregistrement à jour
- on peut beaucoup plus facilement gérer, si besoin, les droits des utilisateurs (lecture seule, lecture/écriture, admin, ...)
- tu es certain de n'avoir qu'une modification à la fois, donc c't'un peu plus facile pour gérer l'historique
 
Désavantage :  
- faut probablement repenser les formulaires, si l'application est conséquente ça risque de coûter cher
- faut gérer le cas de l'utilisateur qui verrouille un enregistrement avant de partir en week-end (expiration du verrou)


 
En pratique, comment faire ? Pour faire une mise à jour, deux étapes sont donc nécessaires :
- la lecture de l'enregistrement souhaité, à la fois pour récupérer les informations et le bloquer (lock) ;
- mettre les informations à jour dans l'enregistrement dans la base de donnée, enregistrement auquel on a un accès exclusif. On libère ensuite les locks.
 
Mais chaque étape va se faire dans une transaction et le fait de la valider (commit) ou l'annuler (rollback) ne lève-t-il pas les locks apposés ?

n°1683480
Elmoricq
Modérateur
Posté le 07-02-2008 à 17:59:38  profilanswer
 

Il n'est bien entendu pas question d'utiliser les verrous de la base de données pour ce genre de système, ils ne sont pas faits pour ça. [:dawao]

n°1683790
yannick_fr​ere
Posté le 08-02-2008 à 09:12:31  profilanswer
 

Ah d'accord ...
 
Donc au cours de la première transaction, tu vas écrire quelque part que tel utilisateur bloque l'enregistrement. Tu stockes ça soit dans une table séparée, soit dans un champ prévu à cet effet dans la table contenant les enregistrements potentiellement bloquables.
 
Et puis à la seconde étape, tu vérifies d'abord si l'initiateur de la transaction a le droit d'écrire (donc, s'il avait précédemment locké l'enregistrement) et puis tu fais ou non la maj ...
 
C'est bien quelque chose dans ce goût-là, ou je suis complètement à côté de la plaque ? ^^'

n°1685032
MagicBuzz
Posté le 11-02-2008 à 19:19:16  profilanswer
 

Bof, ça dépends, avec Générix en tout cas, c'est bien un lock Oracle qui est levé lorsqu'on modifie une fiche (c'est bourrin mais au moins c'est safe et pas de risque d'oubli :D)

Message cité 1 fois
Message édité par MagicBuzz le 11-02-2008 à 19:19:31
n°1685043
Elmoricq
Modérateur
Posté le 11-02-2008 à 20:39:20  profilanswer
 

MagicBuzz a écrit :

Bof, ça dépends, avec Générix en tout cas, c'est bien un lock Oracle qui est levé lorsqu'on modifie une fiche (c'est bourrin mais au moins c'est safe et pas de risque d'oubli :D)


Ce qui impose d'être en lock by row, ce qui est loin d'être anodin sur les tables qui vivent beaucoup d'accès concurrentiels. :D


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C#/.NET managed

  [Résolu] Comment gérer les accès concurents ?

 

Sujets relatifs
[resolu]passage de php4 à php5.... petit problème[RÉSOLU] Warning: mysql_fetch_row(): supplied argument
simuler l'autocomplétion en ligne de commande ? [RESOLU][Résolu] [WSQL] Besoin d'aide - Procedure
[Résolu] addslashes() vs mysql_escape_string()[résolu] Eclipse me crée des classes en ...$1.class
[Resolu] Php + plusieurs bases Accesstrier après une requète (résolu)
[Resolu] Condition pour changer une class[Résolu] Une boucle dans une requête SQL?
Plus de sujets relatifs à : [Résolu] Comment gérer les accès concurents ?


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR