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.

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 !    

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

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)

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 !
 
Lionel.

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.

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 !

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.  

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 )

le mieux reste de loguer les transactions... afin de savoir qui à fait la modif en dernier

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.

 
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 ?

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.

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 ? ^^'

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 )

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.