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

Question

我正在瀏覽有關Transaction的ACID屬性，並在不同站點遇到下面的語句ACID是事務保證的四個屬性的首字母縮寫：原子性，一致性，隔離和持久性。

**我的問題是關於這個短語。

交易保證

**。 根據我的經驗，這些屬性不會被事務自動處理。 但作為Java開發人員，我們需要確保滿足這些屬性標准。

讓我們來看看每個房產： -

1. 原子性： - 假設我們創建客戶時，應該創建帳戶，因為它是強制性的。 因此，現在在交易期間，客戶在創建帳戶期間創建了一些異常oocurs。 因此開發人員現在可以采用兩種方式：要么回滾完整的事務（在這種情況下滿足原子性），要么他提交事務以便創建客戶而不是帳戶（這違反了原子性）。 那么責任在於開發者？

2. 一致性： - 同樣的理由也適用於一致性

3. 隔離： - 根據定義，隔離使事務在不受其他進程或事務干擾的情況下執行。
   但是，當我們將隔離級別設置為Serializable時，就可以實現這一點。 其他情況下，例如讀取提交或讀取未經修改的更改對其他事務是可見的。 那么開發人員有責任讓它與Serializable真正隔離嗎？

4. 持久性： - 如果我們提交事務，那么即使應用程序崩潰，也應該在重新啟動應用程序時提交。 不確定是否需要由開發人員或數據庫供應商/事務處理？

因此，根據我的理解，這些ACID屬性不會自動保證; 相反，我們作為開發者可以實現它們。 如果以上對每一點的理解是正確的，請告訴我？ 如果你們可以回復每一點，我們將不勝感激（是/否也會這樣做。

根據我的理解，read提交應該是大多數應用程序中最符合邏輯的隔離級別，盡管它也取決於要求。

Answer 1

交易保證ACID或多或少：

1）原子性。 交易保證所有更改均已完成或均未進行。 但您需要手動設置事務的開始和結束，並手動執行提交或回滾。 根據您使用的技術（EJB ...），事務是容器管理的，將開始和結束設置為您正在創建的整個“方法”。 如果調用的方法需要新事務或現有事務，沒有事務，您可以通過配置進行控制...

2）一致性。 由原子性保證。

3）隔離。 您必須定義應用程序所需的隔離級別。 根據數據庫，容器定義默認值...最常見的是READ COMMITTED。 請注意鎖定，因為根據您的邏輯和隔離級別會造成死鎖。

4）耐久性。 完全由數據庫管理。 如果您的提交執行沒有錯誤，幾乎所有數據庫都保證更改的持久性，但某些情況可能導致無法保證（寫入磁盤緩存在內存中並在以后刷新...）

通常，您應該了解事務並在代碼聲明的容器中配置星號和結尾（提交，回滾）。

Answer 2

1. 數據庫事務是原子的：它們要么全部發生，要么根本不發生。 就其本身而言，這並未說明商業交易的原子性。 將業務事務映射到數據庫事務有各種策略。 在最簡單的情況下，業務事務由一個數據庫事務實現（其中業務事務通過回滾數據庫中止而中止）。 然后，數據庫事務的原子性意味着業務事務的原子性。 但是，一旦業務事務跨越多個數據庫事務，事情變得棘手......
2. 往上看。
3. 你的陳述是正確的。 通常，較弱的保證足以證明其正確性。

4. 數據庫事務是持久的（除非存在硬件故障）：如果事務已提交，其效果將持續到其他事務更改數據。 但是，如果數據庫或數據庫與調用代碼之間的網絡出現故障，則調用代碼可能無法了解事務是否已發出錯誤。 因此

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

   是錯的。 如果交易已經提交，則沒有什么可做的。

總而言之，數據庫確實提供了強有力的保證 - 關於數據庫的行為。 顯然，它無法保證整個應用程序的行為。