在我們的應用程序中處理java中的併發請求

Question

，如果用戶以管理員身份登錄，他可以執行任何操作。如果第二個管理員同時檢查了相同的路線併爲相同的路線創建了airwaybill，則假定一個管理員修改了路線。這將是一個問題。我無法找到我的應用程序如何處理這些併發請求。 （我們只是使用jdbc交易）

我得到了我的團隊的不同答案1. web /應用程序服務器處理這些事務，它將處理併發請求，沒有任何問題。 2.鎖將發生在數據庫上的行上，並不會有任何併發​​請求的問題。

bottomline：併發請求應該在代碼中處理？或者我們將在部署時在Web /應用程序中爲併發請求進行任何設置？或者默認數據庫會通過行鎖機制來處理併發請求？

如果有人知道在哪裏可以找到解決方案，請告訴我。

Answer 1

據我所知，大多數數據庫引擎在查詢過程中使用某種鎖定，但會因引擎而異。我知道InnoDB強制執行交易原子性（see this stack exchange thread），所以在交易中封裝的任何東西都不會在執行過程中受到干擾。然而，對於哪個請求首先到達數據庫沒有任何保證。

至於webServer/appServer，假設你使用了一個線程化的web服務器：apache tomcat，jetty等，然後每個請求都由一個單獨的線程來處理，所以我認爲它沒有固有的線程安全。在大多數情況下，數據庫將不會抱怨地處理您的併發性，但是我會建議在應用程序端包含某種序列化，以防您決定在某處改變數據庫實現，您還可以更好地控制請求的方式被處理。

簡而言之，做兩個。

Answer 2

據我所知，大多數數據庫在事務和查詢期間都有某種鎖定，但您應該檢查數據庫引用以確保它使用的鎖定方法的類型。至於你的web服務器的問題，我知道tomcat併發地處理請求，併爲它自己的資源提供某種線程安全性，但它不會爲你的應用程序提供線程安全性。因此，你應該自己做。對於上面提到的問題，我認爲當你訪問你的路由時，你應該在數據庫中查詢它是否存在。另外當你的其他管理員修改路由時，你可以在你正在做的那個塊上使用某種鎖，這樣當另一個管理員同時想要訪問正在修改的路由時，他會等待事務處理完成。如果您在服務器端使用java，我建議查看java同步方法或其他語言，請檢查該語言的鎖定和線程安全方法。