你錯過了什麼 - 我非常想:合理的系統設計。 ;)使用數據庫憑證管理用戶的整個想法恰好適用於管理數據庫的一個用例。對於其他所有問題,它會帶來更多的問題,因爲它會帶來更多的問題......所以讓我們開始吧......)
BOT:有一個兩難的問題。您基本上必須爲每個用戶創建一個連接池,因爲否則每次數據源在連接超時運行時都必須創建與數據庫的連接。三次握手加認證不是一件便宜的事情 - 延遲會導致你的表現。雖然有些驅動程序可以進行相應的配置,但總的來說這是一個糟糕的主意,而且大多數驅動程序由於所謂的「關注點分離」而不善於自己管理連接。另一方面,每個連接「池」只需要大約5個連接,因爲同一用戶不太可能並行執行多個操作。
注意:我知道的唯一一個驅動程序管理連接和池的驅動程序是體面的。
現在問題在於:您無法將連接池附加到會話。不是沒有走幾英里,我懷疑這是完全可能的。
解決此問題的一個想法是,當用戶登錄並使用JNDI動態註冊時,爲用戶創建連接池。問題是這不是很有伸縮性(假設你有幾百個用戶)。因此,當會話終止時(無論是通過註銷還是超時),您都必須確保刪除該池。另外,代碼必須保留。
另一個想法是使用Apache Shiro並編寫一個自定義Realm,它只是試圖登錄數據庫來檢查憑據,如果失敗則拋出AuthenticationExcepion。這裏的折衷是你每次都必須初始化連接,這有一些延遲。您的領域甚至可能使用應用程序範圍的連接池,並檢查數據庫元數據以獲取身份驗證和授權數據。當然,這將使得有必要以特權用戶的身份訪問數據庫 - 這是一個可怕的想法。底線:不管你用哪種方式來看待它,通過數據庫管理應用程序認證和授權需求可能會消除應用程序中的認證和授權層,但是反過來需要一個額外的抽象層(你不需要'如果某些數據庫機制發生了變化,是否需要更改服務的代碼?),當我們看到並將代碼綁定到一個數據庫時,會產生可伸縮性問題(當然,除非您需要細粒度的權限並且可以與「工作,沒有工作」的結果)。
您可能想要檢查從['DataSource.getConnection(username,password)'](http://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html #getConnection-java.lang.String-java.lang.String-)根本就是共享的(我見過的池和沒有的池)。 – 2014-11-02 08:06:01