Si je me trompe, il semble que ce dont vous parlez est une forme de workflow de style check-out/edit/check-in. Vous voulez qu'un utilisateur édite un enregistrement, aucun autre utilisateur ne peut même commencer à éditer le même enregistrement.
Il s'agit d'une forme de concurrence pessimiste. optimiste concurrence simultanée - c'est-à-dire, ils vous diront que quelqu'un d'autre a déjà modifié l'enregistrement lorsque vous avez essayé d'enregistrer. Optimistic n'a aucune notion de verrouillage, vraiment - il s'assure qu'aucun autre utilisateur n'a enregistré entre le temps que vous avez récupéré et le temps que vous économisez. Ce que vous voulez n'est pas une exigence facile sur le web, puisque le serveur n'a vraiment aucun moyen d'imposer l'enregistrement quand un utilisateur annule une modification (par exemple, en fermant le navigateur). Je ne suis pas au courant des cadres qui gèrent cela en général.
Fondamentalement, ce dont vous avez besoin est de conserver les informations de paiement sur le serveur. Un processus utilisateur lors de l'édition devrait demander une extraction, et le serveur l'accorderait/le refuserait en fonction de ce qu'il vérifie. Le serveur doit également contenir les informations que la ressource est extraite. Lorsqu'un utilisateur enregistre le serveur, il libère le verrou et autorise une nouvelle extraction à la demande. Le problème survient lorsqu'un utilisateur annule l'édition - si c'est par l'intermédiaire de l'interface utilisateur, pas de problème ... dites simplement au serveur de libérer le verrou. Mais si c'est à travers la fermeture du navigateur, la mise hors tension de la machine, etc, alors vous avez un verrou orphelin. La plupart des gens résolvent l'une des deux façons suivantes: 1. Un délai d'expiration. La serrure sera finalement libérée. L'avantage ici est que c'est assez facile et fiable. Les inconvénients sont que l'enregistrement est verrouillé pendant un moment où il n'est pas vraiment en édition. Et, vous devez faire votre temps d'attente suffisamment long pour que si l'utilisateur prend vraiment très, très longtemps pour enregistrer, ils n'obtiennent pas une erreur parce que le verrou a expiré (et ils doivent recommencer). 2. Un battement de coeur. L'utilisateur envoie périodiquement une requête ping au serveur pour dire "oui, encore en train d'éditer". C'est essentiellement l'option de délai d'attente de # 1, mais avec un délai d'attente très court qui peut être actualisé à la demande. L'avantage est que vous pouvez le rendre arbitrairement court. L'inconvénient est une complexité accrue et l'utilisation du réseau.
Les jetons check-in/checkout ne sont vraiment pas si difficiles à mettre en œuvre si vous avez déjà un stock persistant transactionnel (comme une DB): la partie difficile l'intègre dans votre expérience utilisateur.
Je ne suis pas tout à fait sûr que je suis. Êtes-vous à la recherche d'un système de verrou pessimiste qui empêche l'utilisateur d'éditer quelque chose qui, selon lui, est en cours de modification? OU cherchez-vous quelque chose d'optimiste qui permet plusieurs modifications, mais qui rejette les soumissions lorsque les données ont changé? – AnthonyWJones
Le scénario de verrouillage pessimiste est trop limitatif, donc je suis en train de rayer l'idée.Je ne veux pas que les utilisateurs modifient pendant 30 minutes pour rejeter leurs modifications quand quelqu'un d'autre les a battus pour soumettre un changement. –
Mais le scénario de fusion optimiste nécessite beaucoup de travail de ma part, car j'aurai besoin d'un outil qui permette au client de fusionner des propriétés publiques sur des objets, probablement à la manière d'une grille. –