当有多个并发事务时,会发生丢失更新异常。来自一个或多个事务的更新可能会丢失,因为其他事务会用其结果覆盖它。
让我们通过一个例子来检验一下。考虑以下执行事务的方法。
public void withdraw(Long accountId, double amount) {
Account account = accountRepository.findById(accountId).orElseThrow(() -> {
throw new IllegalStateException("account does not exist: " + accountId);
});
double newBalance = (account.getBalance() - amount);
if (newBalance < 0) {
throw new IllegalStateException("there's not enough balance");
}
account.setBalance(newBalance);
accountRepository.save(account);
}
只要在任何给定时间点只有单个事务交易,这段代码会按预期工作。
当有多个同时事务时会发生什么?
在这种情况下,上述代码将无法正常工作。线程 1 对 newBalance 所做的修改线程 2 是看不到的。因此,它可能会破坏数据。当我们用 @Transactional 对方法进行注解时,行为不会发生变化。反正它只是定义应用程序的事务边界。
如何防止损失更新异常?
请注意,Spring 默认遵循底层数据存储的隔离级别。Postgres 的默认隔离级别是 READ_COMMITTED。这意味着它只能看到查询开始前提交的数据,而看不到未提交的数据或查询执行期间并发事务提交的更改。
实际上,我们可以通过原子更新操作来解决这个问题!
怎么做?
使用本地更新查询,在数据库中执行直接更新,而不是使用普通 ORM 风格的 "选择、修改和保存"。
@Transactional
public void withdraw(Long accountId, double amount) {
Double currentBalance = accountRepository.getBalance(accountId);
if (currentBalance < 0) {
throw new IllegalStateException("there's not enough balance");
};
accountRepository.update(accountId, amount);
}
因此,我们使用了自定义更新方法,而不是通常的保存方法。这种更新方法具体是怎样的呢?
下面是在存储库类中添加的更新方法:
@Transactional
@Modifying
@Query(nativeQuery = true,
clearAutomatically=true,
flushAutomatically=true,
value = """
update account
set balance = (balance - :amount)
where id = :accountId """
)
public int update(Long accountId, Double amount);
请注意,我们在这两个方法中都使用了 @Transactional 注解。但它们属于两种不同类型的 Bean:一种来自服务,另一种来自存储库类。因此,更新方法遵循自己的事务定义。
- @Modifying 会触发注解为 UPDATE 查询的方法,而不是 SELECT 查询。
- 由于在执行Update修改查询后,实体管理器(EntityManager)中可能会包含过时的实体,所以它不会自动清除它,因此,我们需要明确说明 clearAutomatically=true。
- 在执行Update修改查询之前,我们还需要自动清除持久化上下文中的任何受管实体。因此使用 flushAutomatically=true。
实现并发安全的更多方法
1、对任何更新使用悲观锁
将下面的注解与现有的事务注解一起使用:
@Lock(LockModeType.PESSIMISTIC_WRITE)
2、使用数据存储特定的咨询锁
在 postgres 中使用 pg_try_advisory_xact_lock 咨询advisory锁,同时使用超时和键(通常是数据库主键)。
将其与retry 重试模板一起使用,这样它就会不断重试,直到获得主键锁的指定超时为止。
示例:
@Transactional
public void tryWithLock(String key, Duration timeout, Runnable operation) {
lock(key.getKey(), timeout);
// your DB updates run here. operation.run();
}
private void lock(final String key, Duration timeout) { //尝试获取锁,直到超时结束 retryTemplate.execute(retryContext -> {
boolean acquired = jdbcTemplate
.queryForObject("select pg_try_advisory_xact_lock(pg_catalog.hashtextextended(?, 0))", Boolean.class, key);
if (!acquired) {
throw new AdvisoryLockNotAcquiredException("Advisory lock not acquired for key '" + key + "'");
}
return null;
});
}
您可以直接在 JPA 查询中使用咨询锁,这样会简单得多。
@Transactional
@Query(value = """
select c
from Account c
where c.id = :accountId
and pg_try_advisory_xact_lock(
pg_catalog.hashtextextended('account', c.id)
) is true """
)
public Account findByIdWithPessimisticAdvisoryLocking(Long accountId);
3、在 POJO 类中使用带版本号的乐观锁
在 POJO 类中添加注释为 @Version 的属性。
然后使用常规的 Spring JPA 查询来获取更新数据。
在将更新写入数据库之前,Spring JPA 会自动检查版本。如果有任何脏写入,事务将中止,客户端可以使用新版本重新尝试事务。这最适合大容量系统。
4、使用悲观的 NO_WAIT 锁定
@Transactional
@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("select c from Account c where c.id = :accountId")
@QueryHints({
@QueryHint(name = "javax.persistence.lock.timeout", value = (LockOptions.NO_WAIT + ""))
})
public Account findByIdWithPessimisticNoWaitLocking(Long accountId);
在这种情况下,线程不会因为写操作释放锁而无限期阻塞。相反,它会在上述 javax.persistence.lock.timeout 之后立即返回锁获取失败。如果需要,我们也可以处理此异常并重试事务。文章来源:https://www.toymoban.com/news/detail-813641.html
https://www.jdon.com/71719.html文章来源地址https://www.toymoban.com/news/detail-813641.html
到了这里,关于Spring Boot中操作数据库的几种并发事务方式的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!