Dos personas abren el mismo pedido. Una cambia la dirección de entrega y otra la referencia. Ambas guardan y el segundo envío restaura silenciosamente la dirección antigua porque el formulario contenía una copia anterior. Las dos vieron éxito, pero desapareció un cambio aceptado.
Es un problema de actualización perdida. Afecta a pantallas administrativas, importaciones, sincronización móvil y procesos en segundo plano. La concurrencia optimista permite detectar cambios posteriores a la lectura para resolver el conflicto deliberadamente, en lugar de sobrescribir por accidente.
Identifica dónde importan los cambios en competencia
Empieza por registros editables por varias personas o procesos. Incluye formularios abiertos mucho tiempo y guardados demorados. Una pantalla usada por pocos puede tener un riesgo importante si permanece abierta una hora mientras otra persona modifica el registro.
En una empresa hipotética de logística, distintas funciones actualizan instrucciones de entrega, asignación y referencias de facturación. Enumera cambios independientes y los que invalidan decisiones ajenas. Esto da una base de negocio para elegir el comportamiento ante conflictos.
Revisa también escritores no interactivos. Una integración nocturna puede competir con el navegador de un administrador. Proteger solo el botón de guardar no resuelve nada si otra vía sobrescribe sin una comprobación compatible.
Detecta que el registro cambió
EF Core admite concurrencia optimista mediante tokens configurados. Al actualizar o eliminar, el token original participa en la operación; si no se afecta a la fila esperada, puede notificarse un conflicto. En SQL Server, rowversion es una opción específica y no representa una fecha ni una hora. Documentación de concurrencia de EF Core.
Conserva la versión original desde la lectura hasta el intento de actualización del cliente. Si el servidor vuelve a cargar la actual y la trata como original, pierde la prueba necesaria para detectar un formulario antiguo. Aclara su papel en contratos y pruebas.
Trata la versión enviada como condición de concurrencia, no como permiso. Sigue autenticando, comprobando propiedad y validando la operación. Detectar bien un conflicto no sustituye las reglas ordinarias de acceso y negocio.
Decide qué significa el conflicto para el usuario
Elige una respuesta acorde a los datos. En un campo independiente de poco impacto puede combinarse de forma controlada. En una dirección o aprobación quizá haya que revisar el registro y decidir otra vez. Evita una política silenciosa de sobrescritura para todo.
Conserva los cambios intentados el tiempo necesario para compararlos con lo actual. Un error que vacía el formulario y exige empezar de nuevo convierte la protección en pérdida frustrante de trabajo. Presenta diferencias pertinentes en lenguaje comprensible.
En logística, muestra que la dirección cambió durante la edición e identifica los campos en conflicto cuando corresponda. Permite conservar la referencia solo si es coherente con el proceso. Registra una anulación explícita cuando el negocio exija responsabilidad sobre esa elección.
Conecta la resolución con las reglas del negocio
Valida de nuevo frente al estado actual antes de aceptar. Un pedido editable al cargarlo puede estar enviado ahora. Aunque un campo pueda combinarse técnicamente, el negocio quizá ya no permita cambiarlo por la misma vía.
Considera operaciones sobre varios registros. Un token en una fila no protege automáticamente invariantes relacionadas, como capacidad calculada entre varias reservas. Utiliza transacciones y estrategia de base adecuadas y prueba operaciones competidoras que puedan violar la regla.
Distingue conflicto de actualización y creación duplicada inicial. Un token sobre una fila existente no resuelve toda carrera para crear registros. Pueden necesitarse restricciones de unicidad e identidad de solicitud significativa. Ajusta el mecanismo al fallo que pretende prevenir.
Gestiona reintentos según la operación
Algunas operaciones automáticas pueden cargar el estado actual, recalcular su cambio y reintentar con límites. Otras requieren una nueva decisión. Repetir sin cambios una actualización antigua puede generar conflictos continuos o terminar aplicando un resultado ajeno a la intención original.
Limita reintentos y muestra contención persistente. Si una tarea compite constantemente con un proceso interactivo, quizá haya que revisar responsables o diseño. Investiga el patrón en lugar de aumentar simplemente el contador.
En cambios del usuario, explica si se rechazó, aplicó parcialmente o quedó pendiente. Prefiere transacciones de resultado claro. «Algo salió mal» fomenta clics repetidos y dificulta a soporte saber qué llegó a la base.
Prueba la competencia y supervisa el resultado
Crea pruebas que lean dos veces el registro, apliquen un cambio e intenten después la actualización antigua. Comprueba base de datos y respuesta al llamador. Incluye eliminación, permisos revocados y estados importantes, además de dos ediciones de texto sin relevancia.
Utiliza la persistencia real cuando el comportamiento dependa de la base. Un proveedor sustituto u objeto en memoria puede tener otra semántica. Mantén pruebas concretas para la base elegida junto a comprobaciones rápidas de reglas y documenta qué demuestra cada capa.
Worktechlabs mejora la fiabilidad de aplicaciones empresariales multiusuario, incluidos procesos sin conexión y reglas de dominio. Haz explícitos los cambios en competencia, conserva el trabajo durante la resolución y mide los conflictos recurrentes para mejorar el proceso además del guardado.
Fuentes oficiales y lecturas adicionales
- Microsoft: conflictos de concurrencia en EF Core — tokens, detección y resolución.
- Microsoft: validación del modelo de dominio — invariantes al aplicar cambios.
