Como se deve lidar com um javax.persistence.optimisticlockexception?

Question

Eu sou novo no JPA, então me perdoe se não estiver claro.

Basicamente, quero evitar modificações simultâneas usando o bloqueio otimista. Eu adicionei o atributo @version à minha classe de entidade.

Preciso saber se esse algoritmo no manuseio do otimisticlockexception é sólido. Eu vou usar o Execute em torno do idioma igual a:

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();
    }
}

A pergunta que tenho é como você decide quando parar de tentar novamente?

Answer 1

A pergunta que tenho é como você decide quando parar de tentar novamente?

Na minha opinião, o bloqueio otimista deve ser usado ao modificar o mesmo objeto ao mesmo tempo é uma situação excepcional.

Agora, se essa situação ocorrer, e se o processo fosse manual, eu avisaria ao usuário que as modificações não poderiam ser salvas e pedirem que ele salve suas mudanças novamente.

Se o processo for automatizado, pode fazer sentido implementar um mecanismo automático de repetição, mas eu não tentaria mais do que algo como 3 ou 5 vezes, dependendo do tempo de processamento (e eu usaria chamadas recursivas para implementar isso). Se um processo automatizado falhar 5 vezes em uma fileira em um problema de acesso simultâneo, provavelmente está competindo com outro processo automatizado e eles não estão trabalhando em pedaços independentes de dados (o que é ruim para a paralelização) ou a estratégia simplesmente não é o certo. Em ambos os casos, tentar novamente não é a solução certa.