pesimista frente concurrencia optimista (Bloqueo contra Comentarios)

Question

Estoy construyendo una aplicación con los siguientes criterios:

• elementos de trabajo: los tejidos que necesitan ser resueltos de forma manual a través de la web por los usuarios (forma corta una página)
• que varios usuarios trabajen '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
• Usuarios puede sacar 'elementos de trabajo' de las colas de otras personas asignándoselos a sí mismos

Nota: los 'elementos de trabajo' se trabajan solo una vez. Esta no es una página wiki, es más un ejercicio de coincidencia que solo debe realizarlo un usuario. Una vez que el 'elemento de trabajo' se ha trabajado, se ha ido 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 apoye 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'. Ellos 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 tirar de 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 entrará en vigencia en la base de datos y se informará al usuario B de que sus cambios no 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 pessimistic versos optimistic 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 los conflictos potenciales) son comunes, entonces el control de concurrencia pesimista puede ser apropiado, de lo contrario, la concurrencia optimista será más rápida y más sencilla de trabajar.

Avisadme si desea ver ejemplos de código utilizando RowVersion tipo de datos en SQL Server (que es lo que estoy usando actualmente), es bastante sencillo, aunque:

• Todas las tablas incluyen la columna rowversion
• Todos Las consultas SELECT incluyen esta columna (para los 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 y luego alguien más ha tocado la fila, no hay actualizaciones, así que cuéntale al usuario al respecto. 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, al igual que devolvería el Id de una columna de identidad después de una inserción.

Answer 2

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

Answer 3

No estoy seguro de cómo describir la forma en términos simples, pero no es una página comunitaria , es una cosa de una vez. Hipotéticamente, digamos que el usuario tenía para que coincida con el nombre John DOEE a uno de el siguiente John Doe Jon Do Una vez ha funcionado, la edición está completa. En nuestro caso, no sería necesario que la mera

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