更新 JPA(Hibernate) 实体的更好方法是：事务性还是非事务性，为什么？

Question

我有一种情况，我必须在两个选项之间做出选择，但我不清楚这些选项之间有什么区别。如果有人可以向我解释我应该选择哪一个以及为什么，我将非常感激。长话短说，我有一个简单的 JPA 实体（Kotlin 语言）：

@Entity
@Table(name = "account")
data class AccountEntity(
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    var id: Long,

    var balance: Int,

    @ManyToOne
    var accountType: AccountTypeEntity
)

在业务逻辑层，我想要一种通过其 accountId 更新帐户余额的方法。基本上我需要通过 id 加载帐户实体，然后设置新的余额，最后使用 Hibernate 提供的保存方法。但我也发现如果我的方法将用@transactional 注释，我不需要以显式形式调用 save 方法。所以从那时起我有两个选择

第一

fun updateAccountBalance(id: Long, balance: Int) {
    val account = accountRepository.findById(id).orElseThrow { RuntimeException("No account with id=$id found") }
    account.balance = balance
    accountRepository.save(account)
}

第二个

@Transactional
fun updateAccountBalance(id: Long, balance: Int) {
    val account = accountRepository.findById(id).orElseThrow { RuntimeException("No account with id=$id found") }
    account.balance = balance
}

首先，我不清楚这些选项在数据库方面的区别是什么。你能澄清一下吗？

其次，我认为在这种方法中，我根本不需要 TRANSACTION（就数据库而言），因为我只进行一个“写入”操作，对我来说，使用它来避免以显式形式调用休眠保存方法看起来是多余的。但可能是我错了，即使在这里也有一些理由使用事务。所以请纠正我。

Answer 1

在这种情况下，差异几乎没有。第一个示例还创建了一个事务，因为当没有正在运行的事务可供采用时，它将由 save() 调用创建。只要 save() 调用，它就会存在。在第二个示例中，您自己创建一个事务，该事务基本上与方法调用一样长。由于这些方法中几乎没有逻辑，因此它们的足迹几乎是相同的。

这不是一个很好的例子来尝试解决这个问题，因为它太简单了。当您对实体执行更复杂的更新（可能会同时触及多个表和记录）时，事情会变得更有趣，特别是当您开始进行更改时，这将导致在修改 OneToMany 集合时发生级联持久、更新和删除。

想象一个处理订单的系统。订单有订单行。并且订单与发票挂钩。订单行与发票行相关联。也许订单有父订单，因为它们被分组在一起。付款分为与订单、订单行、发票和发票行相关的预订和预订行。想象一下这样的实体层次结构在单个 save() 语句中做了什么。

在这种情况下，就更清楚为什么像 save() 这样的函数仍然会创建事务；一次 save() 调用仍然可以代表正在执行的一条到数千条语句，具体取决于实体层次结构的复杂性。必须能够在发生故障时回滚所有更改。

当您开始使用这样的实体结构时，您可能会很快地倾向于使用设置，因为您迟早@Transactional会遇到臭名昭著的延迟初始化错误。