En este artículo
LAS IDEAS CLAVE
- 01
Detectar una versión antigua y resolver el conflicto son responsabilidades diferentes que deben quedar en el alcance.
- 02
El negocio define qué cambios pueden convivir y quién decide ante diferencias.
- 03
La aceptación necesita dos sesiones, cambios comprobables y un resultado final explicable.
Identifica el conflicto que debes resolver
Imagina una solicitud interna ficticia. Operaciones y Finanzas abren el mismo registro. La primera persona cambia la fecha de entrega; la segunda modifica el centro de costo. Si el segundo guardado envía también la fecha antigua y la aplicación la acepta, puede deshacer el cambio anterior. Ambos usuarios tenían permiso y realizaron acciones legítimas. El problema aparece al combinar sus decisiones.
Antes de contratar, identifica dónde esta situación afectaría el trabajo: solicitudes, fichas de activos, presupuestos o configuración de procesos. Elige ejemplos con las áreas responsables y acuerda qué pérdida sería inaceptable. Esta guía propone criterios de compra y aceptación; los casos son ilustrativos. Si estás reemplazando planillas, complementa la revisión con la guía para pasar de Excel a una aplicación.
Exige comprobar la versión al guardar
HTTP contempla una herramienta para evitar sobrescrituras accidentales: la condición If-Match permite solicitar que una modificación se aplique solo si la representación vigente coincide con la versión indicada mediante su etiqueta. El servidor debe evaluar esa condición antes de ejecutar el cambio. Su existencia en el estándar no demuestra que tu aplicación la utilice. RFC 9110, sección 13.1.1.
Azure Cosmos DB para NoSQL ofrece un ejemplo concreto: cada elemento tiene una etiqueta _etag que cambia al actualizarse; una escritura condicionada con una etiqueta desactualizada se rechaza con HTTP 412. Es una capacidad de ese producto, que debe incorporarse al diseño. Microsoft: concurrencia en Cosmos DB. Pide al proveedor explicar qué mecanismo equivalente usará, qué datos protege y cómo comprobará el resultado desde cada vía de modificación.
Tres alternativas para decidir con negocio y TI
| Alternativa | Cuándo evaluarla | Qué exigir en la demostración |
|---|---|---|
| Recargar y volver a aplicar | El cambio es sencillo de reconstruir. | Conservar la propuesta pendiente, mostrar la versión vigente y permitir retomar sin sobrescribirla silenciosamente. |
| Comparar y resolver | Se necesita revisar diferencias antes de confirmar. | Mostrar el contexto autorizado, elegir los cambios y validar nuevamente el resultado conjunto. |
| Reservar la edición | El proceso necesita un editor responsable a la vez. | Comprobar vencimiento, liberación, recuperación y cumplimiento desde los canales incluidos en el alcance. |
En pantallas pequeñas, desliza la tabla para comparar.
Compara las respuestas que verá la persona
Detectar el conflicto deja una decisión pendiente: cómo continuar. Proponemos comparar las alternativas de la tabla según el trabajo del área. Recargar puede bastar cuando reconstruir el cambio es sencillo, siempre que la persona pueda recuperar lo que escribió. Una comparación asistida merece evaluarse cuando descartar el formulario obliga a repetir un trabajo importante. Una reserva funcional puede servir cuando el proceso exige un editor responsable a la vez.
Las opciones pueden combinarse por tipo de registro. Por ejemplo, una ficha podría permitir edición concurrente y una etapa de aprobación exigir una reserva. Pide justificar cada elección con un escenario concreto. Si el negocio acepta que prevalezca la última escritura en algún dato, deja ese alcance expresamente acordado y comprobable; no permitas que esa decisión aparezca por accidente en toda la aplicación.
Resolver exige conservar contexto y volver a comprobar
La documentación de EF Core distingue los valores originales, los cambios propuestos y los valores actuales de la base de datos al resolver conflictos. La elección o combinación depende de la aplicación y puede requerir una interfaz para el usuario. La detección por sí sola no resuelve esa decisión. Microsoft: manejo de conflictos en EF Core.
Como criterio de aceptación, pide que el aviso identifique qué ocurrió, conserve la propuesta pendiente y explique cómo continuar. La comparación debe mostrar solo información que la persona esté autorizada a consultar. Acuerda quién puede elegir el resultado cuando intervienen áreas distintas. Prueba también que aparezca otro cambio mientras alguien compara versiones: la resolución necesita comprobar de nuevo el estado al guardarse. Reenviar silenciosamente el formulario antiguo impediría saber qué decisión se confirmó.
Distingue una reserva funcional de una transacción abierta
Una reserva visible puede indicar quién tiene a cargo una edición. Su duración y liberación son decisiones del producto. PostgreSQL advierte que mantener transacciones abiertas durante períodos largos, por ejemplo esperando una respuesta humana, es una mala práctica: otras transacciones pueden quedar esperando los bloqueos. Esa advertencia describe el funcionamiento del motor y no equivale a implementar una reserva de formulario. PostgreSQL: bloqueos explícitos.
Si eliges reservar, pide definir qué sucede al cerrar el navegador, perder la conexión o dejar la tarea abandonada. El encargo debe incluir vencimiento, renovación, liberación y recuperación autorizada, con reglas adecuadas al proceso. Comprueba qué verá quien vuelva a una sesión cuya reserva venció. Un aviso de ocupado no basta como evidencia: demuestra que otro canal tampoco puede modificar el registro saltándose la política acordada.
Decide qué cambios pueden convivir
Editar campos distintos no asegura que el resultado conjunto sea válido. En un ejemplo ficticio, una persona cambia la dirección de entrega y otra conserva una ruta de despacho elegida para la dirección anterior. La combinación necesita revisar la regla del proceso. Pide al proveedor identificar qué decisiones se validan juntas y qué cambios podrían aceptarse de manera independiente.
Acuerda también el alcance entre registros relacionados. Proteger una ficha no acredita que una operación sobre varias fichas conserve todas sus condiciones. Revisa con TI las modificaciones por pantalla, API, importaciones o automatizaciones que formen parte del proyecto. Cada entrada debe respetar la misma decisión de negocio. Esta revisión puede descubrir exclusiones de alcance que conviene resolver antes de comparar propuestas económicas.
Acepta la solución con dos sesiones y evidencia
Solicita una demostración reproducible con datos ficticios. Ambas sesiones abren la misma versión; la primera guarda y recibe confirmación; la segunda intenta guardar su versión anterior. Registra qué vio cada persona y qué quedó almacenado. Repite invirtiendo el orden, modificando el mismo campo y cambiando campos relacionados. Si existe reserva, agrega vencimiento y recuperación de la sesión.
Incluye un tercer cambio durante la resolución y comprueba los permisos al confirmar. El informe debe vincular estado inicial, propuestas, decisión autorizada y estado final, con evidencia depurada. Estos ensayos comprueban una política funcional; para evaluar capacidad bajo demanda, define además las pruebas de carga del portal. Son preguntas de aceptación distintas y ambas pueden formar parte del encargo.
Deja la decisión en la propuesta
Antes de aprobar, pide una ficha por proceso con la política elegida, las excepciones, el responsable de resolver, el comportamiento visible y las pruebas requeridas. Incluye qué evidencia se entrega y quién mantiene estas reglas cuando cambien formularios o integraciones. La gerencia debe poder entender qué ocurrirá ante un conflicto; TI debe poder comprobarlo.
Lleva tus ejemplos a una evaluación de desarrollo de software a medida. La conversación será más concreta si muestra dos decisiones legítimas que hoy podrían pisarse y el resultado que necesita el negocio. El objetivo del encargo es que la aplicación conserve una decisión válida y explicable, incluso cuando varias personas trabajan sobre el mismo registro.
Lista de chequeo para aceptar el comportamiento
Marca lo que ya revisaste. Las marcas quedan solo en esta página.
Errores comunes
Aceptar una demostración con un solo editor.
Suponer que campos distintos siempre producen una combinación válida.
Reintentar automáticamente una escritura antigua sin resolver el conflicto.
Confundir el historial de cambios con la prevención de sobrescrituras.
Preguntas frecuentes
¿Dos usuarios pueden editar a la vez sin bloquearse?
Sí, puede diseñarse una edición concurrente con comprobación al guardar. La propuesta debe explicar qué ocurre si otro cambio ya fue confirmado, cómo se conserva el trabajo pendiente y quién resuelve las diferencias.
¿Basta con guardar un historial de cambios?
El historial ayuda a revisar lo ocurrido, pero debe acordarse además cómo impedir o resolver una sobrescritura no autorizada. Pide demostrar tanto el comportamiento al guardar como la evidencia que queda después.
¿La misma regla sirve para todos los campos?
Depende de las relaciones y reglas del proceso. Dos campos pueden necesitar una validación conjunta aunque los editen personas distintas. Define el alcance por operación y compruébalo con ejemplos del negocio.
Guías para evaluar tu proyecto
Si necesitas llevar este tema a tu operación, estos recursos te ayudan a comparar alternativas y preparar el alcance antes de contratar.
CON TEXTO Y CONTEXTO
Fuentes y referencias
- RFC 9110: HTTP Semantics, sección 13.1.1 If-MatchRFC Editor / IETF
- Handling Concurrency ConflictsMicrosoft Learn
- PostgreSQL 18: Explicit LockingPostgreSQL Global Development Group
- Transactions and optimistic concurrency controlMicrosoft Learn
Contenido elaborado con asistencia de IA a partir de las fuentes enlazadas. Las recomendaciones corresponden al análisis editorial de Digital Dev. Cómo elaboramos y corregimos nuestros artículos.