首先，我想確認開發人員是否有責任遵循這些屬性或API等交易Apis的責任？使用JDBC實現ACID屬性？
下面是我的理解，我們如何在JDBC實現耐酸鹼性能
原子性： - 因爲不存在與連接相關聯的一個交易，所以我們提交或回滾，有沒有部分updation.Hence實現
Consitency： - 當某些數據完整性約束條件成立時（比如一些檢查約束），則會拋出sqlexception。然後程序員通過回滾事務來獲得一致的數據庫？
上面的一個問題說我們做了transaction1，並且在上面解釋的事務2期間拋出了sql excpetion。現在我們捕獲異常，並確定提交將首先提交事務？
隔離： - 由JDBC Apis.But提供，這導致了併發更新的問題。所以它已經被人工處理了嗎？
耐用性： - 由JDBC Apis提供。
如果上面的理解是正確的，請讓我來？
事務完整性的ACID原則是由數據庫而不是由API（如JDBC）或由應用程序實現的。您的應用程序的責任是選擇一個數據庫和一個數據庫配置，以支持您所需的任何事務完整性，並正確識別應用程序中的事務邊界。
當引發異常時，應用程序必須確定是否適合回滾整個事務或繼續進行其他處理。如果您的應用程序正在處理來自供應商的訂單（例如處理成功的99個訂單並記錄失敗的1個訂單供用戶調查），這可能是適當的。另一方面，由於1次失敗，您可能會拒絕全部100個訂單。這取決於你的應用程序在做什麼。
通常，您一次只打開一個事務（或者更準確地說，每個連接有一個事務）。因此，如果您在事務2中工作，則事務1按定義已經完成 - 事先已經提交或回滾。事務2中拋出的異常對事務1沒有影響。
根據應用程序請求的事務隔離級別（以及數據庫支持的事務隔離級別）以及應用程序的機制，丟失的更新是您可能需要關注。如果將事務隔離級別設置爲提交讀取，則可能會在事務1中讀取值爲'A'，等待用戶執行某些操作，將值更新爲'B'，然後在未意識到該事務的情況下提交2在您讀取數據和寫入數據之間將值更新爲'C'。這可能是您需要處理的問題，或者可能是最後一個人更新行以「贏」的情況。
另一方面，您的數據庫應負責自動鎖定，以防止兩個事務同時更新同一個表的同一行。它可以通過鎖定超過嚴格限制來實現，但它會以某種方式將更新序列化。