Si estoy en lo cierto, parece que lo que está diciendo es una forma de flujo de trabajo de estilo de salida/edición/registro. Cuando un usuario está editando un registro, ningún otro usuario puede comenzar a editar el mismo registro.
Esto es una forma de concurrencia pesimista. Muchos marcos de acceso web y de datos tienen soporte para la concurrencia optimista optimista, es decir, le informarán que alguien más ya cambió el registro cuando intentó guardar. Optimistic no tiene la noción de bloqueo, en realidad, se asegura de que ningún otro usuario haya guardado entre el momento en que buscó y el momento en que lo guardó.
Lo que desea no es un requisito fácil en la web, ya que el servidor no tiene forma de aplicar el check-in cuando un usuario cancela una edición (por ejemplo, al cerrar el navegador). No estoy al tanto de ningún marco que maneje esto en general.
Básicamente lo que necesita es mantener la información de pago en el servidor. Un proceso de usuario al editar necesitaría solicitar un pago, y el servidor otorgaría/negaría esto en función de lo que están revisando. El servidor también debería contener la información de que el recurso está desprotegido. Cuando un usuario guarda el servidor, libera el bloqueo y permite un nuevo pago cuando se solicita. El problema surge cuando un usuario aborta la edición; si es a través de la interfaz de usuario, no hay problema ... solo dígale al servidor que libere el bloqueo.
Pero si se trata de cerrar el navegador, apagar la máquina, etc., entonces tiene un bloqueo huérfano. La mayoría de las personas resuelve esta de dos maneras: 1. Un tiempo de espera excedido. La cerradura finalmente se lanzará. La ventaja aquí es que es bastante fácil y confiable. Las desventajas son que el registro está bloqueado por un tiempo en el que realmente no está en edición. Y debe hacer que su tiempo de espera sea lo suficientemente prolongado como para que, si el usuario tarda realmente mucho tiempo en guardar, no obtenga un error porque se agotó el tiempo de espera del bloqueo (y tienen que volver a empezar). 2. Un latido del corazón. El usuario tiene un ping periódico al servidor para decir "sí, todavía está editando". Esta es básicamente la opción de tiempo de espera desde el n. ° 1, pero con un tiempo de espera realmente corto que se puede actualizar a pedido. Lo bueno es que puedes hacerlo arbitrariamente corto. La desventaja es una mayor complejidad y uso de la red.
Las fichas de check-in/checkout realmente no son tan difíciles de implementar si ya tiene una tienda persistente transaccionada (como una base de datos): la parte difícil es integrarla en su experiencia de usuario.
No estoy muy seguro de seguir. ¿Está buscando un sistema pesimista de bloqueos que impida al usuario editar algo que cree que ya está en proceso de edición? O ¿está buscando algo optimista que permita la edición múltiple, pero rechaza las presentaciones cuando los datos han cambiado? – AnthonyWJones
El escenario de bloqueo pesimista es demasiado limitado, así que estoy descartando la idea.No quiero que los usuarios editen durante 30 minutos solo para rechazar sus cambios cuando alguien más los golpea para enviar un cambio. –
Pero el escenario de fusión optimista requiere mucho trabajo adicional de mi parte, ya que necesitaré una herramienta que permita al cliente fusionar propiedades públicas en objetos, probablemente en forma de cuadrícula. –