【问题标题】:Execute 2 mthods in a songle transaction with separate Retry logic使用单独的重试逻辑在单个事务中执行 2 个方法
【发布时间】:2021-10-04 08:35:21
【问题描述】:

以下是我的要求

begin trans
insertData();
updateData();
end trans

还可以说 insertDta 方法抛出一些错误然后我需要重试 5 次。与 updateData() 相同。我不应该同时重试这两种方法,即如果我重试 m2() 5 次 m1() 应该不被重试。 下面是正确的方法吗?我从另一个类调用 m3() 。 我担心的是拦截器是以正确和确定的顺序添加的。

@Repository
DaoA
{
    void insertData();
}

@Repository
DaoB
{
    void updateData();
}

下面是我的服务类。

@Service
ServiceA 
{
    
    @Retryable(  maxAttempts = 5)
     public void m1 ()
     {
         
         daoA.insertData();
         
     }
    
    
     @Retryable(  maxAttempts = 5)
     public void m2 ()
     {
          daoB.updateData();
     }
    
    

    @Transactional
     public void m3 ()
     {
         
    
          m1();
          m2();
     }
    

【问题讨论】:

    标签: spring-boot spring-data-jpa spring-jdbc jdbctemplate spring-retry


    【解决方案1】:

    m3() 需要在不同的 bean 中 - 直接在类中调用 m1()m2() 会绕过代理并且不会重试它们。

    在任何情况下,事务都应该在重试逻辑中,而不是相反;您需要为每次尝试启动一个新事务。

    【讨论】:

    • Russel .Supose m1() 工作正常,m2 失败,然后我重试 m3() 3 次。那么 m1 不会插入同一行 3 次吗?。如何使用重试逻辑实现事务对于我的特定场景
    • @Gary 我不认为在同一个类中调用m1()m2()@Retryable 有任何影响。
    • @Gary 我可以用我的代码重试 m1() 5 次(我已经发布了)
    • 如果你从其他bean而不是m3()调用它,它会起作用——通常你会将事务嵌套在重试中;这样,如果 m1,m2 之一失败,另一个将回滚,下一次重试将启动新事务并再次调用这两个方法。
    【解决方案2】:

    如果我的要求正确,这应该适合你。

    @Service
    ServiceA {
        
        public void m1 () {
             daoA.insertData();
         }
        
        public void m2 () {
              daoB.updateData();
        }
    
        @Transactional
        @Retryable(value = {Exception.class}, maxAttempts = 5)
        public void m3 () {
              m1();
              m2();
        }
    }
    

    这将确保重试的总数为maxAttempts = 5

    【讨论】:

    • 是的,但我们不应该在同一方法上使用`@Transactional`和@Retryable
    • @helloworld 为什么会这样?
    • 阅读本文stackoverflow.com/questions/69034571/… Gary Russel 是 Spring-retry 项目的开发人员
    • @helloworld 我认为他想说的是这样做更好,但这种方式也有效。无论如何,您的问题现在已经解决。这才是最重要的。干杯!
    • 正确。跟随他的方式使其具有确定性并且始终以相同的方式运行
    猜你喜欢
    • 1970-01-01
    • 2018-02-24
    • 2015-07-17
    • 1970-01-01
    • 2017-11-07
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-06-29
    相关资源
    最近更新 更多