java - 确保事务的 ACID 属性的责任在哪里？

Question

我正在查看有关事务的 ACID 属性，并在不同站点上遇到了以下声明ACID 是事务保证的四个属性的首字母缩写:原子性、一致性、隔离性和持久性。

**我的问题专门针对这个短语。

guaranteed by transactions

**。根据我的经验，这些属性不受自动交易。但作为 Java 开发人员，我们需要确保满足这些属性标准。

让我们来看看每个属性:-

1. 原子性:- 假设当我们创建客户时，帐户也应该创建，因为这是强制性的。所以现在在交易期间客户在帐户创建过程中创建时出现一些异常。所以开发人员现在可以采取两种方式:要么他回滚完成交易(在这种情况下满足原子性)或者他提交交易所以客户将被创建但不是帐户(这违反了原子性)。所以责任在于开发者？

2. 一致性:- 同样的原因也适用于一致性

3. 隔离:- 根据定义，隔离使事务的执行不受其他进程或事务的干扰。
   但这是在我们将隔离级别设置为可序列化时实现的。否则在另一种情况下，如读取已提交或读取未提交更改对其他交易可见。因此，责任在于开发人员使其真正与 Serializable 隔离？

4. 持久性:- 如果我们提交事务，那么即使应用程序崩溃，它也应该在应用程序重新启动时提交。不确定它是否需要由开发人员或数据库供应商/交易来处理？

因此，根据我的理解，这些 ACID 属性不能自动得到保证；相反，我们作为开发人员应该实现它们。请告诉我以上对每一点的理解是否正确？如果你们能对每一点进行回复，我们将不胜感激(是/否也可以。

根据我的理解，已提交读应该是大多数应用程序中最符合逻辑的隔离级别，尽管它也取决于要求。

Answer 1

事务或多或少保证了 ACID:

1) 原子性。事务保证进行所有更改或不进行任何更改。但是需要手动设置一个事务的开始和结束，手动commit或者rollback。根据您使用的技术(EJB...)，事务是容器管理的，将开始和结束设置为您正在创建的整个“方法”。您可以通过配置来控制调用的方法是需要新事务还是现有事务，没有事务...

2) 一致性。由原子性保证。

3) 隔离。您必须定义应用程序需要的隔离级别。默认值根据数据库、容器定义...最常见的是 READ COMMITTED。小心使用锁，因为它可能会导致死锁，具体取决于您的逻辑和隔离级别。

4) 耐用性。完全由数据库管理。如果你的提交没有错误地执行，几乎所有的数据库都能保证更改的持久性，但有些情况可能会导致无法保证(写入磁盘会缓存在内存中并稍后刷新......)

一般情况下，你应该了解事务并在代码声明的容器中配置它的启动和结束(提交，回滚)。