确保事务的酸性属性的责任在哪里？
我正在研究有关事务的ACID属性，并在不同的站点上看到下面的语句，ACID是事务所保证的四个属性的缩写:原子性、一致性、隔离性和持久性。
**我的问题是关于这个短语的。
事务担保的
**。根据我的经验，这些属性不是由事务自动处理的。但是作为一个java开发人员，我们需要确保这些属性条件得到满足。
让我们检查一下每一处房产：-
- 原子性：-假设当我们创建客户时，帐户也应该创建，因为它是强制性的。因此，现在在事务处理期间，客户被创建，而在帐户创建过程中，一些例外oocurs。因此，开发人员现在可以采取两种方法:要么回滚完整的事务(在本例中满足原子性)，要么提交事务，以便创建客户，而不是创建帐户(这违反了原子性)。因此，责任在于developer?
- Consistency:-，同样的原因也适用于一致性，
- 隔离:-按照定义，隔离使事务执行而不受其他进程或事务的干扰。
但是，当我们将隔离级别设置为Serializable时，就实现了这一点。在另一种情况下，其他的如对其他事务是可见的。因此，如果我们提交事务，那么即使应用程序崩溃，在重新启动应用程序时，开发人员也有责任使它与Serializable?
- Durability:-真正隔离。不确定是否需要由开发人员或数据库vendor/transaction?
来处理
因此，根据我的理解，这些ACID属性并不是自动保证的；相反，作为开发人员，我们应该能够实现它们。请让我知道以上对每一点的理解是否正确？如果你们能回答每一点(是/否也可以)，我会很感激的。
根据我的理解，read提交应该是大多数应用程序中最符合逻辑的隔离级别，尽管它也取决于需求。
回答 2
Stack Overflow用户
发布于 2011-09-11 15:25:10
这些交易或多或少地保证了酸：
1)原子性。事务保证所有更改都已完成，或者没有任何更改。但是，您需要手动设置事务的开始和结束，并手动执行提交或回滚。根据您使用的技术(EJB.)，事务是容器管理的，设置创建的整个“方法”的开始和结束。如果调用的方法需要新事务或现有事务，则可以通过配置来控制.
2)一致性。原子性保证。
3)隔离。必须定义应用程序所需的隔离级别。默认值取决于数据库、容器.最常见的是“承诺”。根据您的逻辑和隔离级别，请小心可能导致死锁的锁。
4)耐久性。完全由数据库管理。如果没有错误地执行提交，几乎所有的数据库都保证更改的持久性，但是有些情况可能导致无法保证(写到磁盘被缓存在内存中，然后刷新.)
通常，您应该知道事务，并将其配置在通过代码声明星型和结束(提交、回滚)的容器中。
Stack Overflow用户
发布于 2011-09-11 15:27:56
- 数据库事务是原子的:它们要么全部发生，要么根本不发生。就其本身而言，这并没有说明业务事务的原子性。将业务事务映射到数据库事务有多种策略。在最简单的情况下，业务事务由一个数据库事务实现(其中业务事务通过回滚数据库事务而中止)。然后，数据库事务的原子性意味着业务事务的原子性。然而，一旦业务事务跨越几个数据库事务，事情就变得棘手了.
- (见上文)。
- 您的陈述是正确的。通常，较弱的保证足以证明correctness.
- Database事务是持久的(除非有硬件故障)：如果事务已提交，其效果将持续到其他事务更改数据为止。但是，如果数据库或数据库与调用代码之间的网络失败，调用代码可能无法了解事务是否已出现。因此
如果我们提交了事务，那么即使应用程序崩溃，它也应该在重新启动应用程序时提交。
是错的。如果事务已经提交，就没有什么可做的了。
总之，数据库确实提供了强有力的保证--关于数据库的行为。显然，它不能保证整个应用程序的行为。
https://stackoverflow.com/questions/7379064
复制相似问题
腾讯云开发者
