¿Cómo maneja / reacciona a la concurrencia de entrada del usuario en la capa GUI?

Question

¿Cuáles son buenas maneras de manejar la concurrencia de entrada del usuario?

Como las respuestas a esta pregunta ya descartan el bloqueo de la base de datos , ¿cómo maneja las entradas simultáneas de usuarios en general?

¿El bloqueo siempre es una mala idea, incluso si no se implementa mediante el bloqueo de filas? ¿Existen mejores prácticas que no dependen del caso de uso? ¿Cuáles fueron sus experiencias con sus estrategias?

EDITAR: Soy consciente de manejar la concurrencia a nivel de datos a través de transacciones: si dos usuarios disparan simultáneamente un cambio de datos complejo, la transacción lo manejará.

Pero estoy interesado en manejar o al menos reaccionar ante ellos en la capa GUI. ¿Qué pasa si el cambio de datos es parte de una operación larga con interacción del usuario?

Digamos que dos o más usuarios están editando el mismo archivo a través de una interfaz web. En algún momento, uno de los usuarios presiona el botón Guardar. ¿Qué pasa con los otros usuarios?

• ¿Serán notificados y / o forzados a recargar? ¿O eventualmente sobrescribirá los cambios del primer usuario?
• ¿Debo bloquear el archivo y evitar que varios usuarios editen el mismo archivo?
• ¿Puedo poner todo el proceso de edición en una transacción (lo dudo mucho, pero quién sabe ...)

¿Cuál es la mejor manera de manejar esta y otras situaciones similares? ¿Hay alguna otra estrategia?

Answer 1

La mejor estrategia depende de lo que debería suceder desde la perspectiva del proceso (comercial); también las preguntas importantes son qué esperarían normalmente los usuarios y qué les sorprendería menos, y, por supuesto, si es factible implementar lo que esperan.

Su ejemplo de edición de un archivo en la web puede desglosarse de la siguiente manera:

1. usuario1 comprueba out / gets / downloads / opens file v0
2. comprobaciones de usuario2 out / gets / downloads / opens file v0
3. usuario1 realiza cambios en su copia de archivo v0
4. usuario2 realiza cambios en su copia de archivo v0
5. user1 guarda la versión de archivo v1 en el servidor
6. user2 guarda la versión de archivo v2 en el servidor

Tenga en cuenta que es típico de las aplicaciones web y, de hecho, también de los programas normales de oficina de escritorio, que los cambios más recientes que el usuario realiza solo estén disponibles (para otros) después de guardarlos, lo que significa que no se trata de tener la escritura del colega aparece encima de la suya en la copia del archivo que está editando.

Un enfoque clásico de control de versiones para esto es que para el usuario1 nada cambia en comparación con el proceso normal de edición / guardado de escritorio.

Sin embargo, para el usuario2, cuando intenta guardar la v2 en el servidor, la aplicación debe verificar si ha habido cambios en la versión del archivo v0 desde la última vez que el usuario la descargó. Como este es el caso, un sistema de control de versiones generalmente le mostraría ambas versiones (v1 y v2) en la pantalla una al lado de la otra, y le permitiría mezclarlas y guardar la versión resultante (v3) en el servidor.

Para los archivos de texto existen varias herramientas y sistemas tanto en Unix como en Windows que intentan automatizar el proceso para que si las áreas del archivo editado no se superponen, los cambios se fusionan automáticamente.

La alternativa es bloquear el archivo para el usuario2 hasta que el usuario1 haya terminado de editarlo.

Poner la edición en una transacción generalmente no tiene relevancia. Es la operación final que intenta sobrescribir el archivo existente con una nueva versión, eso es importante. La edición se realiza de forma independiente en la estación de trabajo de cada usuario y no toca el servidor hasta el último punto (guardar).

---

Su ejemplo es, por cierto, claramente diferente de otra situación, como reservar boletos de avión o reservar una cita con un médico.

Al reservar boletos, hay un número limitado de asientos en un avión. Es posible, debido al hecho de que la transferencia de datos no es realmente instantánea para que más de una persona haga una reserva en el mismo último asiento en un avión.

Por lo tanto, la reserva debe ser al menos un proceso de 2 pasos:

1. el sistema muestra espacios libres;
2. usuario pide uno de los tragamonedas gratis (s1);
El sistema
3. le dice al usuario si la ranura todavía es gratis, y si es así, se lo reserva.
4. el usuario completa la reserva.

El " realmente todavía libre " el paso se debe a que la información sobre las vistas de los usuarios de la página web generalmente no se actualiza en tiempo real, por lo que entre los pasos 1 y 2, es posible que otro usuario haya solicitado el espacio libre.

Answer 2

Busque cómo manejar " transacciones " en cualquier idioma / API de base de datos que esté utilizando. Si los diseñas correctamente, lo manejará por ti.

Y para comprender la teoría, recomendaría Sistemas distribuidos por Couloris et al. pero hay muchos otros buenos libros.