Concessivisme pessimiste vs optimiste (verrouillage versus rétroaction)

Question

Je construis une application avec les critères suivants:

• éléments de travail: éléments devant être manipulés manuellement par les utilisateurs via le Web (formulaire abrégé d'une page)
• Plusieurs utilisateurs travaillent sur des "éléments de travail"
• Chaque utilisateur dispose d'une file d'attente d '"éléments de travail"
• Une recherche permet aux utilisateurs d'afficher des "éléments de travail" et d'affecter des "éléments de travail" à leurs files d'attente
• Les utilisateurs peuvent extraire des "éléments de travail" des files d'attente d'autres personnes en les attribuant à eux-mêmes

Remarque: les "éléments de travail" ne sont traités qu'une seule fois. Ce n'est pas une page wiki, c'est plus un exercice de correspondance qui ne devrait être effectué qu'une seule fois par un seul utilisateur. Une fois que l'élément de travail est traité, il est supprimé du système (à l'exception de certains audits / rapports), un peu comme un système de suivi des bogues

Selon vous, quelle option est la meilleure? Pouvez-vous citer des applications grand public qui appuient votre opinion?

Option 1:

• Lorsque l'utilisateur A va afficher ou utiliser un "élément de travail", celui-ci est verrouillé.
• Lorsque d'autres utilisateurs accèdent à "l'élément de travail" après que l'utilisateur A a ouvert "l'élément de travail", ils ne pourront voir que "l'élément de travail". Ils ne peuvent pas écrire.
• Le verrou expire au bout de n minutes, heure à laquelle un autre utilisateur peut verrouiller l'élément de travail.

Option 2:

• Tout utilisateur peut extraire un "élément de travail" sans le verrouiller.
• Si l'utilisateur A utilise l'élément de travail en soumettant le formulaire et que l'utilisateur B utilise le même "élément de travail", le travail de l'utilisateur A sera appliqué à la base de données et l'utilisateur B sera informé que ses modifications n'ont pas eu lieu. affecter car un autre utilisateur a modifié le "work item".

Personnellement, j'aime bien l'option 2. Vos pensées, s'il vous plaît?

Answer 1

On dirait que vous parlez de pessimiste vers optimiste , contrôle de la concurrence.

Les deux sont largement utilisés. Personnellement, je trouve la concurrence optimiste plus facile à gérer, mais cela dépendra de vos propres besoins et de votre utilisation. Si les modifications (et les conflits potentiels) sont courantes, un contrôle pessimiste de la concurrence peut être approprié. Sinon, la concurrence optimiste sera plus rapide et plus simple à utiliser.

Si vous souhaitez voir des exemples de code utilisant RowVersion , voyez-les. type de données dans SQL Server (c'est ce que j'utilise actuellement), c'est assez simple:

• Toutes les tables incluent la colonne RowVersion
• Toutes les requêtes SELECT incluent cette colonne (pour les données pouvant être modifiées)
• Toutes les requêtes UPDATE ou DELETE incluent WHERE RowVersion = @RowVersion. C’est la partie optimiste. Si 0 ligne est renvoyée, une autre personne l’a touchée, aucune mise à jour n’a lieu, informez-en l’utilisateur. REMARQUE: Si la ligne a été mise à jour, la nouvelle valeur de RowVersion doit également être renvoyée. Cela s'applique également aux requêtes INSERT, comme si vous retourniez l'ID d'une colonne d'identité après une insertion.

Answer 2

  

Vous ne savez pas comment décrire la forme dans   termes simples, mais ce n'est pas une communauté   page, c'est une chose une fois.   Hypothétiquement, supposons que l'utilisateur ait   pour faire correspondre le nom John DOEE à l'un des   John Doe Jon Do une fois   ça marche, le montage est terminé. Dans   notre cas, nous n’aurions pas besoin de simplement

Compte tenu de ce commentaire, je choisirais l'option 1. Etant donné que ces changements sont des changements ponctuels, il n'y a aucun avantage à permettre à plusieurs personnes de travailler sur le même changement. Vous ne faites que perdre le temps de la deuxième personne.

Answer 3

Personnellement, je choisirais l'option 2 - plus, le cas échéant (par exemple, ces modifications portent sur un texte plus long), il incombe à l'utilisateur B de fusionner les modifications. Donnez à B un outil pour le faire.