确保事务的 ACID 属性的责任在哪里？
我正在查看有关事务的 ACID 属性，并在不同站点上遇到了以下声明 ACID 是事务保证的四个属性的缩写：原子性、一致性、隔离性和持久性。
**我的问题具体是关于这个短语的。
交易保证
**。根据我的经验，这些属性不受 自动交易。但作为 Java 开发人员，我们需要确保满足这些属性标准。
让我们详细介绍一下每个属性：-
原子性：- 假设当我们创建客户时，也应该创建帐户，因为这是强制性的。所以现在在交易过程中 在帐户创建过程中发生一些异常时创建客户。因此，开发人员现在可以采用两种方法：要么回滚 完成交易（在这种情况下满足原子性）或者他提交交易，因此将创建客户但不会创建客户 帐户（违反了原子性）。那么责任在于开发人员？
一致性：- 相同的原因对于一致性也有效
隔离：- 根据定义，隔离使事务执行时不受其他进程或事务的干扰。< br> 但这是当我们将隔离级别设置为 Serialized 时实现的。否则在另一种情况下，例如读已提交或读未提交 更改对其他事务是可见的。那么开发人员有责任使其真正与可序列化隔离吗？
持久性：-如果我们提交事务，那么即使应用程序崩溃，也应该在应用程序重新启动时提交。不确定是否需要由开发人员或数据库供应商/事务处理？
因此，根据我的理解，这些 ACID 属性不会自动得到保证；相反，我们作为开发人员应该实现它们。请告诉我 上述对每一点的理解是否正确？如果你们能够回答每一点，我将不胜感激（是/否也可以。
根据我的理解，已提交的读应该是大多数应用程序中最逻辑的隔离级别，尽管它也取决于需求。
I was going through ACID properties regarding Transaction and encountered the statement below across the different sites
ACID is the acronym for the four properties guaranteed by transactions: atomicity, consistency, isolation, and durability.
**My question is specifically about the phrase.
guaranteed by transactions
**. As per my experience these properties are not taken care by
transaction automatically. But as a java developer we need to ensure that these properties criteria are met.
Let's go through for each property:-
Atomicity:- Assume when we create the customer the account should be created too as it is compulsory. So now during transaction
the customer gets created while during account creation some exception oocurs. So the developer can now go two ways: either he rolls back the
complete transaction (atomicity is met in this case) or he commits the transaction so customer will be created but not the
account (which violates the atomicity). So responsibility lies with developer?Consistency:- Same reason holds valid for consistency too
Isolation :- as per definition isolation makes a transaction execute without interference from another process or transactions.
But this is achieved when we set the isolation level as Serializable. Otherwis in another case like read commited or read uncommited
changes are visible to other transactions. So responsibility lies with the developer to make it really isolated with Serializable?Durability:- If we commit the transaction, then even if the application crashes, it should be committed on restart of application. Not sure if it needs to be taken care by developer or by database vendor/transaction?
So as per my understanding these ACID properties are not guaranteed automatically; rather we as a developer sjould achieve them. Please let me know
if above understanding regarding each point is correct? Would appreciate if you folks can reply for each point(yes/no will also do.
As per my understanding read committed should be most logical isolation level in most application, though it depends on requirement too.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事务或多或少保证了ACID：
1）原子性。事务保证进行所有更改或不进行任何更改。但需要手动设置事务的开始和结束，并手动执行提交或回滚。根据您使用的技术（EJB...），事务由容器管理，为您正在创建的整个“方法”设置开始和结束。您可以通过配置来控制调用的方法是否需要新事务或现有事务，没有事务...
2) 一致性。由原子性保证。
3）隔离。您必须定义应用程序所需的隔离级别。默认值是根据数据库、容器定义的...最常见的是 READ COMMITTED。请小心锁，因为根据您的逻辑和隔离级别，锁可能会导致死锁。
4）耐用性。完全由数据库管理。如果您的提交执行没有错误，则几乎所有数据库都保证更改的持久性，但某些情况可能会导致无法保证（对磁盘的写入缓存在内存中并稍后刷新...）
一般来说，您应该了解事务并配置它在容器中通过代码声明星号和结束（提交、回滚）。
The transactions guarantees ACID more or less:
1) Atomicity. Transaction guarantees all changes are made or none of them. But you need to manually set the start and end of a transaction and manually perform commit or rollback. Depending on the technology you use (EJB...), transactions are container-managed, setting the start and end to the whole "method" you are creating. You can control by configuration if a method invoked requires a new transaction or an existing one, no transaction...
2) Consistency. Guaranteed by atomicity.
3) Isolation. You must define the isolation level your application needs. Default value is defined depending upon the database, container... The commonest one is READ COMMITTED. Be careful with locks as can cause dead-lock depending on your logic and isolation level.
4) Durability. Managed entirely by the database. If your commit executes without error, nearly all database guarantees durability of changes, but some scenarios can cause to not guarantee that (writes to disk are cached in memory and flushed later...)
In general, you should be aware of transactions and configure it in the container of declare by code the star and end (commit, rollback).
数据库事务是持久的（除非出现硬件故障）：如果事务已提交，其效果将持续到其他事务更改数据为止。但是，如果数据库或数据库与调用代码之间的网络发生故障，调用代码可能无法了解事务是否已提交。因此
<块引用>
如果我们提交事务，那么即使应用程序崩溃，也应该在应用程序重新启动时提交。
是错误的。如果事务已提交，则无需执行任何操作。
总而言之，数据库确实对数据库的行为提供了强有力的保证。显然，它不能保证整个应用程序的行为。
Database transactions are durable (unless there is a hardware failure): if the transaction has committed, its effect will persist until other transactions change the data. However, calling code might not learn whether a transaction has comitted if the database or the network between database and calling code fails. Therefore
is wrong. If the transaction has committed, there is nothing left to do.
To summarize, the database does give strong guarantees - about the behaviour of the database. Obviously, it can not give guarantees about the behaviour of the entire application.