multiusuario registro de aplicación de bloqueo - el mejor método?

Question

Estoy desarrollando una aplicación PHP / MySQL que se encarga de múltiples usuarios simultáneos. Estoy pensando en el mejor enfoque a tomar cuando se trata de bloqueo / advertencia contra los registros que actualmente están siendo ver / editar.

El escenario es evitar dos usuarios que ven el registro, uno de hacer un cambio, entonces el otro haciendo lo mismo -. Con la posibilidad de que un cambio podría sobrescribir el anterior

En las últimas versiones de WordPress que utilizan algún método para detectar esto, pero no parece totalmente fiable -. A menudo regresan falsos positivos, al menos en mi experiencia

Asumo alguna forma de ajax debe estar en su lugar a 'ping' de la aplicación y que éste sepa el registro todavía se está viendo / editado (de otro modo, un usuario puede simplemente cerrar la ventana de su navegador, y luego cómo sabría la aplicación ese).

Otra solución que pude ver es comprobar la última vez actualizado cuando se envía un registro de actualización, para ver si en el ínterin se ha actualizado en otro lugar - y luego ofrecer al usuario una opción para continuar o descartar sus propios cambios.

Tal vez estoy ladrando al árbol equivocado en términos de una solución - ¿Cuáles son los pueblos experiencias de aplicación de la presente (lo que debe ser un bastante común) Requisito

Answer 1

Me gustaría hacer esto: Grabar la hora de la última modificación en el formulario de edición. Comparar esta vez en la presentación con el tiempo almacenado en la base de datos. Si son iguales, bloquear la tabla, actualizar los datos (junto con la fecha de modificación) y desbloquear la tabla. Si los tiempos son diferentes, notificar al usuario acerca de ello y pedir el siguiente paso.

Answer 2

véase: ¿Qué puedo hacer para prevenir conflictos de escritura y escritura en un sitio web al estilo wiki?

Answer 3

Buena idea con la comparación de marca de tiempo. Es barato de implementar, y que es una operación de bajo costo para ejecutar en la producción. Sólo tienes que escribir la lógica para enviar de vuelta al usuario el mensaje de estado que su escritura / actualización no se produjo porque alguien les adelantó.

Tal vez considere almacenar el nombre de usuario en cada actualización en un campo llamado algo así como 'LastUpdateBy', y volver de nuevo a que el usuario que tenía su actualización vaciado anteriormente. Sólo un poco de sutileza para el usuario. Niza, en el sentido corporativo, tal vez no en un entorno en el que podría no ser apropiada.