当我们提供事务管理apis时，为什么在Hibernate中默认为autocommit为false？

Question

我们在提供事务管理apis时，没有清楚地知道为什么autocommit在Hibernate中默认为false。 我有三个问题

1. 为什么Hibernate不建议使用自动提交模式？

2. 当我们使用autocommit = true然后使用Hibernate Transaction apis进行事务管理时会发生什么？

3. 使用spring声明式事务管理时@Transactional（readonly = true）如何帮助我们编写的只读代码（Hibernate代码）？

Answer 1

我将逐一回答从（2）开始，因为我不太了解（1）

（2）：autocommit = true表示默认情况下所有查询都被提交。在这种情况下如果

• 如果方法上有@Transactional，它会覆盖自动提交并将所有查询包含在单个事务中，从而覆盖自动提交

• 如果有一个@Transactional方法调用其他@Transactional注释方法，则最外层注释应覆盖内部注释并创建更大的事务，因此注释也会覆盖彼此。

（3）：在像Oracal / Mysql这样的数据库中，只读事务可以转换为READ_ONLY级别，它不提供脏读，不提供不可重复的读操作但不允许任何更新。这意味着刷新模式将在当前Hibernate会话中设置为FlushMode.NEVER，以防止会话提交事务。甚至会在JDBC连接上调用setReadOnly(true)，这确保您无法调用session.flsuh（）甚至手动刷新会话。

由于Spring本身并不执行持久性，因此无法指定readOnly应该具有什么意义。这个属性只是对提供者的一个提示，行为取决于，在这种情况下，Hibernate。

Answer 2

关于（1）：

假设您拥有一家公司并拥有1000名员工。您将维护一个数据库表，以跟踪员工是否在月底获得了薪水。

所以，我们到了月底和发薪日。工资单发送给您一个excel文件 有600个名字刚刚获得上个月的薪酬。因此，您登录计算机并启动Java应用程序，然后选择Excel将所有600条记录保存到数据库中。通常需要2分钟，但是现在它在1分23秒时失败。您现在的期望是什么？您希望gosh's知道部分上传的文件知道多少记录，或者什么都不知道吗？自动提交将驱动它：如果autocommit = false，则可以一次又一次地上传整个文件，但是如果autocommit = true，则可能需要先对输入数据进行调整，以删除一些记录，以防止数据库中出现重复记录

我希望，我的简化示例可以帮助您更好地理解它，但真正的目的是确保将批处理中的所有内容（包括每个写入操作，如插入/更新/删除）保存在数据库中，或者确保不进行任何处理。万一在过程中的任何时候发生错误，都可以。在现实生活中，在大多数情况下，您和您的组织将期望数据库中包含完整的数据集，而不是部分数据集。理解它是关键，任何建议“使用autocommit = true因为它是安全的”的人都应该避免。这是一个关键概念，也是数据管理的基础之一。