2011-09-22 17 views
6

Esta es la primera vez que desarrollo una aplicación que será utilizada por 10-15 personas concurentemente, así que no estoy seguro de una buena forma de minimizar las colisiones de actualización.Tratar con un entorno de usuario múltiple

Básicamente, mi aplicación funciona de la siguiente manera. Los nuevos elementos se insertan en la base de datos a través de un servicio externo a medida que se reciben. Las reglas comerciales indican que cada artículo debe ser revisado por dos empleados independientes. Huelga decir que hay una relación uno a muchos entre el artículo y las revisiones. Cuál es el aspecto más importante de la aplicación es que ningún elemento puede superar dos revisiones y el sistema debe realizar un seguimiento de quiénes fueron los dos revisores. Además, quien actuó como el primer revisor y segundo.

Ahora, tengo todo funcionando. El problema que estoy tratando es este (uno de muchos escenarios similares). ¿Qué sucede si todos los usuarios actualizaron su lista de elementos dentro de los mismos 5 minutos de cada uno? El usuario 1 envía una revisión para el ID del ítem 1. Una segunda persona envía una revisión sobre el mismo ítem. Ahora, una tercera persona envía una revisión en el id. De artículo 1, pero ya hay 2 comentarios, por lo que el artículo se ha marcado como completo.

¿Cuáles son las formas posibles de lidiar con un entorno multiusuario en el que existe una gran oportunidad de que varios usuarios actualicen el mismo registro?

Respuesta

7

No sé los detalles de su aplicación, pero parece que el proceso de hacer una revisión amplia la ventana donde múltiples personas pueden iniciar una revisión y luego cuando cometen termina siendo más de dos,

una opción es introducir el concepto de iniciar una revisión. Cuando alguien inicia la acción de hacer una revisión, "comienzan" la revisión. Eso marca la revisión como comenzó. El sistema no debería dejar más de dos comenzando.

También puede hacer que sea más avanzada por el tiempo de espera comentarios que estamos nunca "presentadas" o tener la capacidad de eliminar una revisión pendiente que se inició.

+0

similar a un concepto de check in/check out como lo encontraría en el control de fuente – cordialgerm

5

Nhibernate tiene varios modelos concurrentes que usted implementa en su proyecto según sus necesidades.

Tenga una mirada en NHibernate-Concurrency

+1

un problema con la concurrencia al comprometer la revisión es el revisor que pierde todo el tiempo perdido para escribir la revisión. – bryanmac

+0

Exactamente .so que depende de las necesidades del proyecto. Si alguien puede sobrescribir los cambios o evitar que los datos se actualicen si hay una modificación. –

+0

De acuerdo. Creo que tener a alguien que pueda escribir una reseña completa solo para rechazar en escritura protegida por concurrencia es una mala experiencia. Mis 2 centavos aunque sean técnicamente precisos. – bryanmac

Cuestiones relacionadas