責任在哪裏確保交易的ACID屬性？

Question

我正在審閱有關交易的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. 數據庫事務是持久的（除非存在硬件故障）：如果事務已提交，其效果將一直存在，直到其他事務更改數據爲止。但是，如果數據庫或數據庫和調用代碼之間的網絡出現故障，調用代碼可能無法瞭解事務是否已經完成。因此，

   如果我們提交事務，那麼即使應用程序崩潰，它應該在應用程序重新啓動時提交。

   是錯誤的。如果交易已經發生，就沒有什麼可做的了。

總而言之，數據庫的確提供了有力的保證 - 關於數據庫的行爲。顯然，它不能保證整個應用程序的行爲。