Spring Optimistic Locking: как повторить транзакционный метод, пока фиксация не будет успешной

У меня есть решение, но я думаю, что оно уродливое. Я ловлю все RuntimeException, и это работает только для новых транзакций. Вы знаете, как сделать его лучше? Вы видите проблемы?

Сначала я сделал аннотацию:

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface RetryingTransaction {
     int repeatCount() default 20;
}

Затем я сделал такой перехватчик:

    public class RetryingTransactionInterceptor implements Ordered {
      private static final int DEFAULT_MAX_RETRIES = 20;
      private int maxRetries = DEFAULT_MAX_RETRIES;
      private int order = 1;

      @Resource
      private PlatformTransactionManager transactionManager;

      public void setMaxRetries(int maxRetries) {
          this.maxRetries = maxRetries;
      }
      public int getOrder() {
          return this.order;
      }
      public void setOrder(int order) {
          this.order = order;
      }

      public Object retryOperation(ProceedingJoinPoint pjp) throws Throwable {
          int numAttempts = 0;
          Exception failureException = null;
          do {
                numAttempts++;
                try {
                    DefaultTransactionDefinition def = new DefaultTransactionDefinition();
                    def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
                    TransactionStatus status = transactionManager.getTransaction(def);

                    Object obj = pjp.proceed();

                    transactionManager.commit(status);      

                    return obj;
                } 
                catch( RuntimeException re ) {
                    failureException = re;
                }
          } while( numAttempts <= this.maxRetries );
          throw failureException;
      }
}

Весеннее приложениеConfig.xml:

<tx:annotation-driven transaction-manager="transactionManager" order="10" />

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
    <property name="transactionSynchronizationName">
        <value>SYNCHRONIZATION_ALWAYS</value>
    </property>
</bean>

<bean id="retryingTransactionInterceptor" class="com.x.y.z.transaction.RetryingTransactionInterceptor">
    <property name="order" value="1" />
</bean>

<aop:config>
    <aop:aspect id="retryingTransactionAspect" ref="retryingTransactionInterceptor">
        <aop:pointcut 
            id="servicesWithRetryingTransactionAnnotation" 
            expression="execution( * com.x.y.z.service..*.*(..) ) and @annotation(com.x.y.z.annotation.RetryingTransaction)"/>
        <aop:around method="retryOperation" pointcut-ref="servicesWithRetryingTransactionAnnotation"/>
    </aop:aspect>
</aop:config>

И метод, аннотированный следующим образом:

@RetryingTransaction
public Entity doSomethingInBackground(params)...

Используйте Spring Retry, чтобы повторить весь метод, если проверка номера версии или временной метки не удалась (происходит оптимистическая блокировка ).

Конфигурация

@Configuration
@EnableRetry
public class FooConfig {
     ...
}

использование

@Retryable(StaleStateException.class)
@Transactional
public void doSomethingWithFoo(Long fooId){
    // read your entity again before changes!
    Foo foo = fooRepository.findOne(fooId);

    foo.setStatus(REJECTED)  // <- sample foo modification

} // commit on method end

Конфигурация проекта

Приложение Spring Boot определило действительную версию spring-retry, поэтому требуется только это:

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
</dependency> 

У нас есть это, и что мы делаем, это:

1. Сбросьте сеанс (чтобы убедиться, что предстоящее обновление будет единственным в очереди)
2. Загрузите экземпляр
3. Внесите изменения

4. В StaleObjectStateException очистить очередь действий

   ((EventSource) session).getActionQueue().clear()
   

   и повторите попытку с # 2

У нас есть счетчик повторных попыток, чтобы повторно выдать исключение в конце.

ПРИМЕЧАНИЕ. Это официально не поддерживаемый метод (в Hibernate четко указано, что сеанс, вызвавший исключение, следует отбрасывать и не использовать повторно), но это известный обходной путь (с тем ограничением, что вы не можете выборочно удалить действие обновления, но должны очистить всю очередь).

Здесь отбрасываем еще один вариант: BoneCP (http://jolbox.com) поддерживает автоматический повтор транзакций в случае сбоя (включая когда БД выходит из строя, сеть выходит из строя и т. д.).