请求量稍微比较大-尽量避免长事务

最新推荐文章于 2025-03-27 00:13:24 发布

Sam_Deep_Thinking

最新推荐文章于 2025-03-27 00:13:24 发布

阅读量6.2k

点赞数 6

文章标签：事务并发

本文链接：https://blog.csdn.net/linsongbin1/article/details/71243086

版权

本文讨论了如何通过合理地调整事务范围来优化数据库操作，减少长时间持有数据库连接的情况，从而提高系统的整体吞吐量。介绍了两种不同的事务处理方式及其对数据库连接的影响。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

概述

某些后台应用经常需要频繁的操作DB,为了保证数据出错时能回滚数据,通常都会使用事务。在使用事务的时候,尽量避免使用长事务,比如说:某个业务操作需要批量插入数据,而且数据量还不少,如果这整个操作都包在一个事务里面,只有等到数据操作完了,DB连接才会被释放,一旦外部系统发起请求,并发调用这个操作,那么一下子将有大量的DB连接被持有而没有被释放掉,这个时候,如果还有其他请求到来,就很大可能获取不到数据库连接,请求也就只能等待，整个系统的吞吐量就大大下降。

所以宁愿将事务的范围缩小,快速操作完数据后,立刻把DB连接还给连接池,这样后续的请求就可以拿到连接。
当然这样对DB的压力也会增加,但是总比db连接被耗光来的好。

@Transactional(value="transactionManager",rollbackFor=Exception.class)
public Long addOrUpdateGoodsMerchandise(Object data) {
      //操作table 1
      //操作table2
}

@Transactional(value="transactionManager",rollbackFor=Exception.class)
  for(Object ele : ObjectList){
   public Long addOrUpdateGoodsMerchandise(Object data) {
      //操作table 1
      //操作table2
    }
  }

第二种做法就可能将事务拉长了,DB连接一直被占有着。第一种做法虽然会拿了db连接后又释放,然后又继续拿db连接,操作完后又释放,但是这种连接被持有的时间非常短,其他请求有机会可以拿到这个请求的。

另外现在的db连接池性能都很不错，拿了后又放回去，其实性能也没差多少的。