Version imprimable
Bonjour,
Je mets en place une application Silverlight Business Application et je voulais savoir comment on peut faire en sorte que lorsqu'un utilisateur est entrain de modifier une donnée un autre ne puisse pas le modifier.
Est ce qu'il y a une pratique ou méthode pour faire ça?
C'est un probleme d'acces concurrent ( lock optimiste/pessimiste)
En silverlight tu n'as pas acces aux données directement, le soucis n'est pas donc pas a proprement parler a ce niveau.
Il me semble qu'il y a des mecanismes implementés dans entity framework et wcf dataservices pour gérer ces problemes.
En fait je recherche plus de precision moi aussi :).
Je pense aussi que c'est un pb de base de donnée.
Si tu as besoin de réserver des données pendant un certain temps (de l'ordre de plusieurs minutes), tu peux rajouter à ta donnée deux colonnes : l'id de l'utilisateur qui réserve la donnée et l'heure à laquelle la réservation est effectuée.
Ainsi si une personne veut réserver une donnée, elle vérifiera à la fois si qq à déjà réservé la donnée et si cette réservation est toujours valide (réservation < 20 min par exemple). Si la personne quitte brutalement l'application, la donnée sera libéré toute seule (au bout de 20 min max).
C'est juste une idée :)
La gestion de la synchronisation est une problématique technique qui ne devrait pas polluer le modèle métier.Citation:
Si tu as besoin de réserver des données pendant un certain temps (de l'ordre de plusieurs minutes), tu peux rajouter à ta donnée deux colonnes : l'id de l'utilisateur qui réserve la donnée et l'heure à laquelle la réservation est effectuée.
Ainsi si une personne veut réserver une donnée, elle vérifiera à la fois si qq à déjà réservé la donnée et si cette réservation est toujours valide (réservation < 20 min par exemple). Si la personne quitte brutalement l'application, la donnée sera libéré toute seule (au bout de 20 min max).
Il faut au contraire la gérer dans une couche dédiée sur le serveur : au mieux cela est intégré au SGBD, à EF ou à WCF data-services, au pire il faut implémenter un système de lock dans le WS qui gère l'accès aux données.
Pour ma part je parlais de réservation de donnée et non de synchronisation ce qui n'est pas du tout la même chose. Et je ne vois pas en quoi la réservation ne peut faire partir de la problématique métier ;)Citation:
La gestion de la synchronisation est une problématique technique qui ne devrait pas polluer le modèle métier.
Disons que j'ai interprété :Citation:
Pour ma part je parlais de réservation de donnée et non de synchronisation ce qui n'est pas du tout la même chose. Et je ne vois pas en quoi la réservation ne peut faire partir de la problématique métier
comme une problématique de synchronisation d'accès.Citation:
lorsqu'un utilisateur est entrain de modifier une donnée un autre ne puisse pas le modifier
En effet, il faudrait plus de détails sur la problématique du PO.Citation:
Et je ne vois pas en quoi la réservation ne peut faire partir de la problématique métier
Re,
Merci, vos post m'ont bien aidé. Avec cela, j'ai trouvé un petit article sur l'acces concurentiel avec EF.
Encore merci.
Effectivement, mon problème est la reservation de donnée et non la synchronisation.
Merci pour votre aide
Hello,
@otyv84: peux-tu partager le lien vers l'article que tu as trouvé?
J'ai déjà implémenté de l'optimistic locking, mais jamais du pessimistic... Ca m'intéresse (je vois mal comment on fait).
Merci
A+
Christophe
Je n'ai plus l'adresse, vraiment désolé ! Mais c'est sur MSDN, si ça peut aider !
Sinon, ça marcherait plutot bien de reserver les données ...;
Concernant EF, j'ai vérifié dans le bouquin très complet de Julie Lerman: EF ne supporte que "l'optimistic locking" avec des options différentes de résolution du conflit...
@otyv84: si tu ne retrouves plus le lien, peux-tu nous expliquer en 2 mots comment tu as finalement décidé de faire?
Merci,
A+
J'ai crée une table RESA (ID_Resa, Date, ID_Donnee, ID_User,Resa). Dans mon projet, quand je mets en place un bouton modifier qui rend visible le détail de la donnée à modifier et crée la RESA pour celui ci. En fait l'utilisateur reserve la donnée.