當其他應用程序使用相同的數據庫時JPA的併發

Question

我正在開發Spring MVC JPA Web應用程序。當此應用程序在現場部署時，與我的應用程序交互的相同數據庫將被其他2個Dotnet和VB應用程序同時使用。我通過版本列管理我的JPA應用程序的併發性。

當同一個數據庫同時運行這3個應用程序時是否會有問題？所有系統都使用相同的表格。

我將不得不在未來爲同一個數據庫構建另一個應用程序（很可能是Spring MVC + JPA）。在同時運行兩個應用程序時（在兩個應用程序中保留相同的表等方面），是否會有任何問題？

Answer 1

訪問相同數據庫表的多個應用程序可能（通常是）併發的噩夢。僅向表格添加版本列不會有幫助，因爲每個應用程序都可能使用不同的併發管理機制。用樂觀的整個鎖，另一個使用悲觀鎖定和第三試想一個應用程序：共享跨應用程序數據庫時遇到的常見問題（假設所有，並沒有特定的順序讀寫訪問）：

1. 併發不匹配根本不使用鎖定（因爲所有數據都由不同的團隊維護）。即使有一箇中央架構團隊向每個人發佈了良好的應用架構建議，開發人員也可以做他們喜歡的任何事情，最終導致併發地獄。
2. 死鎖：設想一個應用程序對所有事務使用SERIALIZABLE隔離級別，並對數據庫執行長時間運行的操作，從而導致隊列，死鎖和超時。即使其他應用程序不會破壞數據，它們也可能會因爲死鎖和超時而看到太多錯誤，從而降低了它們的實用性。
3. 數據有效性：開發人員通常使用內存中緩存來存儲固定或緩慢更改的數據以節省重複的數據庫往返時間。在由Hibernate支持的JPA應用程序中，開發人員可以使用二級緩存。但是，如果另一個應用程序更新數據庫，則緩存將保留陳舊（因此不準確）的數據。
4. 數據完整性：不同的應用程序可能使用不同的數據部分。如果所有人都可以獨立更新公共數據，那麼如何維護參照完整性？業務規則怎麼樣？他們必須在應用程序中複製嗎？
5. 團隊溝通開銷：每個團隊必須隨時向其他團隊通報他們需要對架構進行的更改，以便他們不會踩到對方的腳趾。這可能會降低敏捷性，如果其他團隊不同意團隊要求的更改或優先級不一致。
6. 模式錯誤：如果某人刪除，重命名，移動或歸檔應用程序所需的表或列，會發生什麼情況？
7. 訪問控制：如果底層數據是敏感的並且需要身份驗證和授權，則訪問控制檢查將不得不在應用程序中重複。
8. 所有權：誰擁有共同表格會成爲一個挑戰，因爲每個團隊都可能有自己的利益相關者，路線圖，制約因素和優先事項。
9. 可移植性：如果底層數據庫（供應商和類型）必須在某一天更改，則需要更改所有應用程序。
10. 審計和版本控制：如果需要審計和/或版本化（多個版本的數據行）公共數據，則代碼將不得不跨越應用程序進行復制或內置到數據庫中（這可能並不容易例如，數據庫知道哪個應用程序用戶更改了記錄）。如果在數據庫中完成，可移植性會再次受到影響，因爲每個數據庫供應商的語法可能不同。
11. 針對特定數據庫的優化：某些場景（例如報告）可能需要本機查詢或其他優化，這些優化可能無法使用像JPA這樣的ORM技術，或者很難執行。如果多個應用程序需要訪問優化的查詢，那麼這些功能將不得不構建到數據庫（存儲過程）中，或者跨應用程序複製（以可能不同的方式）。
12. 存檔和分區：不同的應用程序可能有不同的存檔和分區要求。誰確保平等滿足每個人的需求？
13. 標準化：如果允許不同的團隊自己管理公共數據庫對象，如何管理數據字典，命名約定等？不同團隊使用的表可能會有不同的（並且大多令人煩惱）命名列，約束等。

更好的方法是使用服務公開數據庫表。該服務可以始終保持事物的一致性和可控性。處理服務變更的公共團隊可確保將意外變更儘量減少，並及時傳達給所有相關方。