我正在浏览有关交易的ACID属性，并在不同网站上遇到以下声明 ACID是事务保证的四个属性的首字母缩写：原子性，一致性，隔离性和持久性。
**我的问题是关于这句话。
由交易保证
**。根据我的经验，这些属性并未得到照顾 交易自动。但作为Java开发人员，我们需要确保满足这些属性标准。
让我们来看看每个属性： -
原子性： - 假设我们创建客户时，应该创建帐户，因为它是强制性的。所以现在在交易期间 在帐户创建期间创建了一些例外oocurs。所以开发人员现在可以采取两种方式：要么他回滚了 完成事务（在这种情况下满足原子性）或者他提交事务以便创建客户但不创建客户 帐户（违反原子性）。那么责任在于开发人员吗？
一致性： - 同样的理由也适用于一致性
隔离： - 根据定义，隔离使事务在不受其他进程或事务干扰的情况下执行 但是，当我们将隔离级别设置为Serializable时，就可以实现这一点。其他情况下的其他情况如读取提交或读取未经通过 更改对其他事务可见。因此开发人员有责任让它与Serializable真正隔离吗？
持久性： - 如果我们提交事务，那么即使应用程序崩溃，也应该在重新启动应用程序时提交。不确定是否需要由开发人员或数据库供应商/事务处理？
根据我的理解，这些ACID属性不能自动保证;相反，我们作为开发者可以实现它们。请告诉我 如果以上对每个点的理解是正确的吗？如果你们大家可以回复每一点，我将不胜感激（是/否也会这样做。
根据我的理解，read提交应该是大多数应用程序中最符合逻辑的隔离级别，尽管它也取决于要求。
答案 0 :(得分：3)
交易保证ACID或多或少：
1）原子性。交易保证所有更改均已完成或均未进行。但您需要手动设置事务的开始和结束，并手动执行提交或回滚。根据您使用的技术（EJB ...），事务是容器管理的，将开始和结束设置为您正在创建的整个“方法”。如果调用的方法需要新事务或现有事务，没有事务......
，您可以通过配置进行控制2）一致性。由原子性保证。
3）隔离。您必须定义应用程序所需的隔离级别。根据数据库，容器定义默认值...最常见的是READ COMMITTED。请注意锁定，因为根据您的逻辑和隔离级别会造成死锁。
4）耐用性。完全由数据库管理。如果您的提交执行没有错误，几乎所有数据库都保证更改的持久性，但某些情况可能导致无法保证（写入磁盘缓存在内存中并稍后刷新...）
一般情况下，您应该了解事务，并在代码声明的容器中配置star和end（commit，rollback）。
答案 1 :(得分：3)
数据库事务是持久的（除非出现硬件故障）：如果事务已提交，其效果将持续到其他事务更改数据。但是，如果数据库或数据库与调用代码之间的网络出现故障，则调用代码可能无法了解事务是否已发出错误。因此
如果我们提交事务，那么即使应用程序崩溃，也应该在重新启动应用程序时提交。
错了。如果交易已经提交，则没有什么可做的。
总而言之，数据库确实提供了强有力的保证 - 关于数据库的行为。显然，它无法保证整个应用程序的行为。