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

Question

我正在浏览有关 Transaction 的 ACID 属性，并在不同的站点上遇到了以下语句 ACID 是事务保证的四个属性的首字母缩写词：原子性、一致性、隔离性和持久性。

**我的问题是关于这个短语的。

由交易保证

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

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

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

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

3. 隔离：- 根据定义，隔离使事务的执行不受其他进程或事务的干扰。
   但这是在我们将隔离级别设置为 Serializable 时实现的。否则在另一种情况下，例如已提交读或未提交读 更改对其他事务可见。所以开发者有责任用 Serializable 真正隔离它吗？

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

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

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

Answer 1

事务或多或少地保证 ACID：

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

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

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

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

一般来说，你应该知道事务，并在通过代码声明星号和结束（提交，回滚）的容器中配置它。

Answer 2

1. 数据库事务是原子的：它们要么全部发生，要么根本不发生。就其本身而言，这并没有说明业务交易的原子性。将业务事务映射到数据库事务有多种策略。在最简单的情况下，业务事务由一个数据库事务实现（其中业务事务通过回滚数据库事务而中止）。那么，数据库事务的原子性意味着业务事务的原子性。但是，一旦业务事务跨越多个数据库事务，事情就会变得棘手......
2. 见上文。
3. 您的说法是正确的。通常，较弱的保证足以证明正确性。

4. 数据库事务是持久的（除非出现硬件故障）：如果事务已提交，其效果将持续到其他事务更改数据为止。但是，如果数据库或数据库与调用代码之间的网络发生故障，调用代码可能无法了解事务是否已提交。因此

   如果我们提交事务，那么即使应用程序崩溃，它也应该在应用程序重新启动时提交。

   错了。如果事务已提交，则无事可做。

总而言之，数据库确实提供了强有力的保证——关于数据库的行为。显然，它不能保证整个应用程序的行为。