Как нужно обработать javax.persistence. OptimisticLockException?

Я плохо знаком с JPA, так простите мне не будучи ясными.

В основном я хочу предотвратить параллельные модификации при помощи Оптимистической Блокировки. Я добавил, что @Version приписывают моему классу объекта.

Я должен знать, является ли этот алгоритм при обработке OptimisticLockException звуковым. Я собираюсь использовать Выполнение Вокруг Идиомы как так:

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

Вопрос, который я имею, состоит в том, как Вы решаете, когда прекратить повторять?

7
задан Community 23 May 2017 в 12:23
поделиться

1 ответ

У меня вопрос, как вы решаете, когда прекратить повторные попытки?

На мой взгляд, оптимистическая блокировка должна использоваться, когда изменение одного и того же объекта в одно и то же время является исключительной ситуацией.

Теперь, если возникнет такая ситуация, и если бы процесс был ручным, я бы предупредил пользователя, что изменения не могут быть сохранены, и попросил бы его снова сохранить свои изменения.

Если процесс автоматизирован, имеет смысл реализовать механизм автоматического повтора, но я бы не стал повторять больше, чем примерно 3 или 5 раз, в зависимости от времени обработки (и я бы использовал рекурсивные вызовы для реализации этого ). Если автоматизированный процесс дает сбой 5 раз подряд из-за проблемы с одновременным доступом, то он, скорее всего, конкурирует с другим автоматизированным процессом, и он либо не работает с независимыми фрагментами данных (что плохо для распараллеливания), либо стратегия просто не работает. правый. В обоих случаях повторная попытка - неправильное решение.

10
ответ дан 7 December 2019 в 01:20
поделиться
Другие вопросы по тегам:

Похожие вопросы: