Concurrencia pesimista versus optimista (bloqueo versus retroalimentación)

Question

Estoy creando una aplicación con los siguientes criterios:

• elementos de trabajo: elementos que los usuarios deben trabajar manualmente a través de la web (formulario corto de una página)
• Múltiples usuarios trabajando 'elementos de trabajo'
• Cada usuario tiene una cola de 'elementos de trabajo'
• Hay una búsqueda que permite a los usuarios ver 'elementos de trabajo' y asignar 'elementos de trabajo' a sus colas
• Los usuarios pueden quitar 'elementos de trabajo' de las colas de otras personas asignándolos a ellos mismos

Nota: los 'elementos de trabajo' se trabajan solo una vez. Esta no es una página wiki, es más un ejercicio de emparejamiento que solo debe ser realizado una vez por un usuario. Una vez que el "elemento de trabajo" funciona, desaparece del sistema (aparte de algunas auditorías / informes), algo así como un sistema de seguimiento de errores

¿Qué opción crees que es mejor? ¿Puedes citar alguna aplicación convencional que respalde tu opinión?

Opción 1:

• Cuando el usuario A va a ver o trabajar un 'elemento de trabajo', el 'elemento de trabajo' se bloquea.
• Cuando otros usuarios van al 'elemento de trabajo' después de que el usuario A abre el 'elemento de trabajo', solo podrán ver el 'elemento de trabajo'. No pueden escribir.
• El bloqueo expira después de n minutos, momento en el que otro usuario puede bloquear el 'elemento de trabajo'.

Opción 2:

• Cualquier usuario puede abrir un 'elemento de trabajo' sin bloquearlo.
• Si el usuario A trabaja el 'elemento de trabajo' enviando el formulario y el usuario B trabaja el mismo 'elemento de trabajo', entonces el trabajo del usuario A tendrá efecto en la base de datos, y el usuario B será informado de que sus cambios no tuvieron efecto afectar porque otro usuario ha modificado el 'elemento de trabajo'.

Personalmente me gusta la opción 2. ¿Pensamientos por favor?

Answer 1

Parece que estás hablando de pesimista versos optimista control de concurrencia.

Ambos son ampliamente utilizados, personalmente encuentro que la concurrencia optimista es más fácil de manejar, pero dependerá de sus propios requisitos y uso. Si las ediciones (y posibles conflictos) son comunes, entonces el control de concurrencia pesimista puede ser apropiado; de lo contrario, la concurrencia optimista será más rápida y sencilla de trabajar.

Avíseme si desea ver ejemplos de código usando RowVersion tipo de datos en SQL Server (eso es lo que estoy usando actualmente), aunque es bastante simple:

• Todas las tablas incluyen la columna RowVersion
• Todas las consultas SELECT incluyen esta columna (para datos que se pueden modificar)
• Todas las consultas UPDATE o DELETE incluyen WHERE RowVersion = @RowVersion. Esta es la parte optimista, si se devuelven 0 filas, alguien más ha tocado la fila, no se realiza ninguna actualización, así que dígaselo al usuario. NOTA: Si se actualizó la fila, también se debe devolver el nuevo valor para RowVersion. Esto también se aplica a las consultas INSERT, de la misma manera que devolvería el Id de una columna de identidad después de una inserción.

Answer 2

  

No estoy seguro de cómo describir el formulario en   términos simples, pero no es una comunidad   página, es una cosa de una vez.   Hipotéticamente, digamos que el usuario tenía   para que coincida con el nombre de John DOEE a uno de   el siguiente John Doe Jon Do Once   está trabajado, la edición está completa. En   nuestro caso, no necesitaríamos meros

Considerando ese comentario, iría con la opción 1. Teniendo en cuenta que estos cambios son cambios únicos, no hay ningún beneficio en permitir que varias personas trabajen en el mismo cambio. Solo estás perdiendo el tiempo de la segunda persona.

Answer 3

Yo personalmente iría con la opción 2 - más, si corresponde (por ejemplo, esas ediciones están en un texto más largo), es responsabilidad del Usuario B fusionar las ediciones. Dele a B una herramienta para hacerlo.