Evitar que los usuarios trabajen en la misma fila

Question

Tengo una aplicación web en el trabajo que es similar a un sistema de trabajo de tickets. Algunos usuarios introducen nuevos problemas. Otros trabajadores eligen y resuelven problemas. Todos los datos se mantienen en MS SQL Server 2005.

Los usuarios que trabajan para resolver problemas van a una página donde pueden ver los problemas abiertos. Debido a que hasta veinte personas pueden ver esta página al mismo tiempo, un problema potencial que tuve que resolver fue lo que sucede si alguien elige un problema que otra persona escogió justo después de que se cargue su página.

Para abordar esto, hice dos cosas. Primero, la vista de cuadrícula que muestra los problemas para seleccionar utiliza un temporizador AJAX para actualizar cada segundo. Una vez que se ha seleccionado un problema, desaparece un segundo después como máximo. En caso de que seleccionen uno dentro de este segundo, reciben un mensaje pidiéndoles que escojan otro.

El problema es que la parte de AJAX de esto está enviando demasiadas actualizaciones (esto es lo que asumo) y está afectando el rendimiento de la página y la base de datos. Además, las actualizaciones no se realizan cada segundo. Encuentro que el temporizador no es confiable cuando se trabaja para activar procedimientos almacenados.

Tiene que haber una mejor manera, pero parece que no puedo encontrar una. ¿Alguien tiene experiencia con una situación como esta o tiene sugerencias para evitar que varios usuarios seleccionen el mismo registro para mantener? Realmente no quiero deshabilitar la parte de AJAX por completo porque creo que el mensaje solo haría que la aplicación fuera frustrante de usar.

Gracias,

Answer 1

Dos cosas pueden ayudar a mitigar tu problema.

Primero, se necesita la notificación posterior a la selección de que se ha tomado el caso, independientemente del período de tiempo de actualización de ajax. Incluso revisar cada segundo no significa que dos personas no puedan hacer clic en el mismo caso en lo que perciben como al mismo tiempo. En tales casos, uno de los usuarios debe ser notificado de que su selección no es válida, aunque parecía válida cuando se seleccionó. Esta notificación no necesita ser elaborada; mantener un tono ligero y útil puede mejorar la percepción del usuario incluso a la luz de la decepción. Y si identifica al usuario que ya seleccionó ese registro, eso no solo ayudará a sus usuarios a coordinarse en el futuro, sino que también desviará la atención de su programa al usuario que arrebató el caso jugoso. (de hecho, a la administración le puede gustar dar a sus usuarios una colisión ocasional, ya que los motivará a seleccionar casos más rápidamente)

En segundo lugar, una pequeña modificación de cómo mostrar sus casos puede reducir las colisiones de selección. Agregar un elemento aleatorio para mostrar el orden y / o filtrar cada otro caso en pantalla ayudará a sus usuarios a seleccionar diferentes casos de forma natural. El reconocimiento de patrones humanos y la selección de tareas no son realmente aleatorios, por lo que pequeños cambios en la presentación pueden igualar grandes cambios en el comportamiento de selección. Las reducciones en la posibilidad de colisión mantienen las notificaciones de colisión raras (y, por lo tanto, menos frustrantes para los usuarios). Esto es aún mejor si sus usuarios pueden ser separados en clasificaciones que pueden ayudar a determinar el orden / filtrado de casos útiles.

Bien, una tercera cosa que lo ayudará con el tiempo es si mantiene un registro de cuándo ocurren las colisiones (con metadatos útiles sobre la colisión, como quién estuvo involucrado y el tiempo de selección). Armado con datos de colisión sólidos, puede encontrar lo que funciona y lo que no. Con el tiempo, puede adaptar su aplicación a sus casos de uso reales, así como identificar posibles problemas en una etapa temprana. Nada tranquiliza a sus usuarios más que estar al tanto de un problema (y poder explicar sus planes para resolverlo) incluso antes de que se den cuenta de que existe.

Con estos patrones de mitigación, es probable que encuentre que puede reducir de forma segura el plazo de sus consultas ajax sin afectar la experiencia del usuario. Y con un registro útil, tendrá la seguridad de que cualquier modificación que realice en realidad funciona (o no & # 8212; lo que quizás sea aún más útil saber).

Answer 2

Coloque un campo de marca de tiempo de bloqueo en la fila en la base de datos. Escriba un proceso almacenado que devuelva verdadero o falso si el timsetamp de vencimiento es anterior a un tiempo específico. Establezca sus sesiones en su aplicación web para que expiren al mismo tiempo, un minuto o dos. Cuando un usuario selecciona una fila, accede al proceso almacenado que ayuda a la aplicación a decidir si debería permitirle al usuario modificarla.

Espero que tenga sentido ....

Answer 3

Hice algo similar en el que una vez que un usuario abrió un ticket (fila) asignó ese ticket a ese usuario y estableció un valor en ese registro, como y FK para ese usuario en particular, así que si alguien más trató de abrir ese ticket ( fila) les avisará que ya se ha asignado a otra persona.

Answer 4

Si es posible, limite el sistema para que solo eliminen el siguiente problema abierto de la cola de trabajo, en lugar de que puedan elegir entre todos los problemas abiertos.

Si eso no es posible, supongo que puede verificar la elección de un problema para ver si todavía está disponible. Si no está disponible, haz que desaparezca después de que el usuario haga clic en él. De esta manera solo está solicitando cuando realmente hacen clic en algo en lugar de un sondeo constante de los datos.

Answer 5

¿Ha intentado aumentar el tiempo entre actualizaciones? Espero que una vez cada 30 segundos sea suficiente. 40 solicitudes / minuto es mucho menos carga que 1200 / minuto. Es posible que sus usuarios ni siquiera noten la diferencia.

Si lo hacen, ¿qué hay de proporcionar un botón de actualización en la página para que los usuarios puedan actualizar manualmente la lista justo antes de seleccionar un elemento para evitar el mensaje molesto si lo desean?

Answer 6

Falta ver el problema, especialmente después de que mencionaste que ya estás marcando tickets en progreso / manteniéndose y tienes una marca de tiempo / versión del artículo.

No es suficiente lo siguiente:

1. El usuario busca los tickets y ve una lista de tickets disponibles, es decir, esto excluye los que están en la db como en progreso. Si desea que los usuarios también vean tickets en curso, indíquelo claramente en el estado del ticket y deshabilite la opción de tomarlo.
2. El usuario marca un ticket como en curso explícita o implícitamente abriendo el ticket (depende de la experiencia del usuario / cómo se presenta a los usuarios).
3. El usuario mueve el ticket explícitamente a un estado diferente, es decir, completado, no válido, en espera de comentarios, etc.

Cuando los elementos se recuperan en 1, incluye una marca de tiempo / versión. Cuando sucede 2, utiliza un enfoque de concurrencia optimista para asegurarse de que si 2 personas intentan actualizar el ticket al mismo tiempo, solo el primero tendrá éxito.

Lo que sucederá es que, para la segunda persona, la actualización ... donde ... timestamp = @timestamp no encontrará ningún registro para actualizar y usted informará que el boleto ya se tomó.

Si lo deseas, puedes construir encima de lo anterior para actualizar la interfaz de usuario a medida que se capturan los tickets. Esto podría ser simplemente haciendo una actualización completa de la página actual de tickets después de x tiempo (tal vez alertando / preguntando al usuario), o incluso recuperando una lista de tickets modificada para la página de tickets que se muestra con ajax. Aún tiene los pasos anteriores en su lugar, ya que esta modificación es solo una conveniencia para los usuarios.