Existen múltiples formas de tratar las solicitudes de usuarios en conflicto. El método que elija simplemente depende de para qué son los datos y cuál es el resultado que desea.
El primer y más simple método es ignorar el problema . Ambos dispositivos enviarán la solicitud, y el que se procesa más adelante anula el primero. Su resultado final será simplemente la transacción que se ejecutó por última vez. Los servidores de archivos simples funcionan de esta manera.
Un segundo método es usar el bloqueo pesimista. Antes de hacer cualquier cambio, el dispositivo dice “Hola, modificaré este recurso, nadie lo toque”. Luego, el usuario realiza el cambio y luego lo confirma. Cuando se compromete el cambio, también dice “Ya terminé”. Supongamos que dos dispositivos intentan bloquear el mismo recurso, uno de ellos recibirá un error que dice “alguien ya tiene este recurso, intente nuevamente más tarde” o simplemente cuelgue hasta que se libere el bloqueo. Algunos ejemplos de esto son sharepoint, Visual Source Safe, Clearcase.
- ¿Qué idiomas y herramientas necesita para vincular una aplicación de Android a la base de datos de un sitio web?
- ¿Cómo aprendemos back-end para el desarrollo de Android?
- ¿Qué análisis / métricas específicos registran los desarrolladores de aplicaciones móviles y cómo?
- ¿Cuáles son algunas buenas prácticas en el desarrollo de aplicaciones de Android?
- ¿Dónde me comunico con los desarrolladores de aplicaciones de Android en India?
Un tercer método es usar un bloqueo optimista. Cuando el dispositivo obtiene una copia del recurso, incluye un número de versión. El dispositivo realiza un cambio, aumenta el número de versión y envía el cambio con el nuevo número de versión. La transacción se acepta solo si el nuevo número de versión es mayor que el actual. Por ejemplo:
- el dispositivo A obtiene el recurso en la versión 1,
- el dispositivo B obtiene el mismo recurso en la versión 1.
- El dispositivo A realiza algunos cambios y envía la actualización con la versión 2.
- El servidor acepta los cambios porque la versión 2 es mayor que la versión 1 que tiene actualmente.
- El dispositivo B realiza algunos otros cambios e intenta enviar la actualización con la versión 2.
- El servidor ve que ya tiene una versión 2 y esta actualización también tiene la versión 2. Por lo tanto, el servidor rechaza la transacción y le dice al Dispositivo B que intente nuevamente o falle.
Algunos ejemplos de esto incluyen CVS, Subversion, Git, etc.
Las bases de datos relacionales pueden usar un bloqueo optimista o pesimista.
