Optimistic Locking en C#: Guía Completa

Introducción: confiar y verificar

Optimistic Locking es opuesto a pessimistic. Asume conflictos son raros. Procede sin bloquear. Al final, verifica si hubo cambios conflictivos. Si no, perfecto. Si sí, retry. Ventaja: sin contención de locks. Desventaja: retries si conflictos. Ideal cuando conflictos <10%. Mecanismo: cada entidad tiene versión (timestamp, counter, hash). Lees versión, modificas, intentas guardar. Si versión cambió, alguien más modificó entre tu lectura y escritura. Abort, retry, merge. El "optimismo" es la suposición que la mayoría del tiempo, nadie modifica datos que estás usando.

1. Naturaleza: compartir y reconciliar

Git es optimistic locking. Múltiples desarrolladores clonan repo (sin locks). Cada uno trabaja independientemente. Al pushear, Git verifica: ¿cambió la rama remota desde mi último pull? Si no, merge automático, push ok. Si sí, push es rechazado, necesitas pull y resolver conflictos. Sin centralizar locking. Si conflictos son raros (típico en equipos bien organizados), es eficiente. Otro ejemplo: Google Docs. Múltiples usuarios editan simultáneamente (sin bloquear líneas). La aplicación usa Operational Transformation o CRDT para resolver conflictos automáticamente. Es optimistic a nivel de párrafos. En vida real, optimistic encaja cuando colaboradores confían que sus cambios no conflictarán.

Prompt: shared notes with versions, soft illustration.

2. Mundo Real: edición concurrente de órdenes

E-commerce: dos usuarios editan la misma orden (cambian cantidades). Usuario A lee orden, precio $100, cantidad 1. Usuario B reads orden, precio $100, cantidad 1. A cambiaridad a 2. B cambia a 3. A save (versión 1 => 2): ok. B save (versión 1 => 3): FALLO, versión es 2 ahora, no 1. B debe recargar, ver cambios de A, resolver conflicto. Sin optimistic, B habría sobrescrito cambios de A silenciosamente. Con optimistic, conflicto detectado. Otro caso: documento compartido. Reportes que múltiples analistas editan. Cada uno tiene timestamp de última modificación. Si alguien modifica, timestamp se incrementa. Intento de guardar verifica timestamp. Funciona porque cambios simultáneos son REALMENTE raros (no 100 analistas editando report al mismo tiempo). Optimistic asume eso.

Prompt: concurrent edits with version conflict, flat infographic.

3. Implementación en C#: Código Paso a Paso

Entity Framework soporta optimistic locking con propiedades Timestamp o rowversion.

public class Order
{
    public int Id { get; set; }
    public string Name { get; set; }
    [Timestamp] // Valor automático del servidor
    public byte[] Version { get; set; }
}

using var db = new OrderContext();
var order = db.Orders.Find(1);
order.Name = "Updated";

try
{
    db.SaveChanges(); // Si Version cambió, DbUpdateConcurrencyException
}
catch (DbUpdateConcurrencyException ex)
{
    // Conflicto detectado. Recargar y reintentar.
    ex.Entries.Single().Reload();
}

El Timestamp es autoincremental. Cada modificación lo incrementa. SaveChanges() verifica: ¿Version en DB == Version que leí? Si sí, ok. Si no, excepción. Catch, reload, retry. Alternativa: versionamiento manual con int counter. Ambos funcionan. Timestamp es más simple.

4. Optimistic vs Pessimistic: elección estratégica

Pessimistic bloquea, optimistic detecta y retries. Pessimistic: contención baja, pero locking overhead. Optimistic: contención baja, sin locking, retries si conflicto. Si conflictos <10% y retries baratos, optimistic gana. Si conflictos >30% o retries caros, pessimistic gana. Caso de uso optimistic: edición de documentos, posts en redes sociales, comentarios. Caso pesimista: inventario, dinero, acciones. En sistemas distribuidos, optimistic es más práctico (locks globales son difíciles). En monolito con sincronización central, pessimistic es más simple. Moderno arquitectura prefiere optimistic porque escala mejor y es más resiliente a network partitions.

5. Diagrama UML y Flujo

El patrón optimistic no tiene estructura compleja. Una entidad con versión. El flujo: lectura => modificación => guardar con verificación de versión. Si version_en_db == version_leída, ok. Si no, conflicto. El diagrama de flujo: dos transacciones leen la misma entidad (versión 1). T1 modifica, guarda (versión 2). T2 intenta guardar (versión 1), pero en DB está 2. Rechazado. T2 recarga, reintenta. Evento: T1 wins, T2 retries. Ambos ven versión final. Diferencia con pessimistic: T2 no espera mientras T1 trabaja; intenta en paralelo, se detiene solo al guardar.

Prompt: UML optimistic locking, clean vector.

Prompt: optimistic locking flow diagram, minimal infographic.

Conclusión

Optimistic Locking es elegante: confía en que conflictos son raros, procede sin locks, verifica al final. Bajo overhead, alto rendimiento con baja contención. Retries si conflictos. Ideal para aplicaciones web, sistemas distribuidos, donde bloqueos centrales son impracticables. Es el patrón moderno para concurrencia.