¿Cómo se debe manejar una javax.persistence.OptimisticLockException?

Question

Soy nuevo en JPA, así que discúlpeme si no lo tengo claro.

Básicamente, quiero evitar modificaciones concurrentes mediante el bloqueo optimista. He agregado el atributo @Version a mi clase de entidad.

Necesito saber si este algoritmo sobre el manejo de OptimisticLockException es sonido. Voy a utilizar el Execute Around Idiom así:

interface UpdateUnitOfWork 
{ 
    doUpdate(User user); /* may throw javax.persistence.PersistenceException */ 
} 

public boolean exec(EntityManager em, String userid, UpdateUnitOfWork work) 
{ 
    User u = em.find(User, userid); 
    if(u == null) 
     return; 

    try 
    { 
     work.doUpdate(u); 
     return true; 
    } 
    catch(OptimisticLockException ole) 
    { 
     return false; 
    } 
} 

public static void main(..) throws Exception 
{ 
    EntityManagerFactory emf = ...; 
    EntityManager em = null; 

    try 
    { 
     em = emf.createEntityManager(); 

     UpdateUnitOfWork uow = new UpdateUnitOfWork() { 
      public doUpdate(User user) 
      { 
       user.setAge(34); 
      } 
     }; 

     boolean success = exec(em, "petit", uow); 
     if(success) 
      return; 

     // retry 2nd time 
     success = exec(em, "petit", uow); 
     if(success) 
      return; 

     // retry 3rd time 
     success = exec(em, "petit", uow); 
     if(success) 
      return; 
    } 
    finally 
    { 
     em.close(); 
    } 
} 

La pregunta que tengo es, ¿cómo decidir cuándo dejar de volver a intentar?

Answer 1

La pregunta que tengo es ¿cómo decides cuándo parar de reintentar?

En mi opinión, bloqueo optimista se debe utilizar cuando se modifica el mismo objeto al mismo tiempo es una situación excepcional.

Ahora, si ocurre esta situación, y si el proceso era manual, le advertiría al usuario que las modificaciones no podrían guardarse y le pediría que guarde sus cambios nuevamente.

Si el proceso es automático, puede tener sentido implementar un mecanismo de reintento automático, pero no volvería a intentar más de algo así como 3 o 5 veces, dependiendo del tiempo de procesamiento (y usaría llamadas recursivas para implementar esta). Si un proceso automatizado falla 5 veces seguidas en un problema de acceso simultáneo, entonces es muy probable que compita con otro proceso automatizado y o bien no están trabajando en trozos independientes de datos (lo cual es malo para la paralelización) o la estrategia simplemente no es lo que es correcto. En ambos casos, reintentar más no es la solución correcta.