但是，我很快發現壹個問題：當多用戶同時並發訪問數據庫的時候會出現資源爭用的問題。這都是“單例模式”惹的禍。眾所周知，我們在使用spring框架的時候，在beanFactory中註冊的bean基本上都是采用單例模式，即spring在啟動的時候，這些bean就裝載到內存中，並且每個bean在整個項目中只存在壹個對象。正因為只存在壹個對象，對象的所有屬性，更準確說是實例變量，表現得就如同是個靜態變量（實際上“靜態”與“單例”往往是非常相似的兩個東西，我們常常用“靜態”來實現“單例”）。拿我們的問題來說，sessionFactory在整個項目中只有壹個對象，它的實例變量dataSource也就只有壹個，就如同壹個靜態變量壹般。如果不同的用戶都不斷地去修改dataSource的值，必然會出現多用戶爭用壹個變量的問題，對系統產生隱患。
通過以上的分析，解決多數據源訪問問題的關鍵，就集中在sessionFactory在執行數據持久化的時候，能夠通過某段代碼去根據客戶的需要動態切換數據源，並解決資源爭用的問題。
采用Decorator設計模式
要解決這個問題，我的思路鎖定在了這個dataSource上了。如果sessionFactory指向的dataSource可以根據客戶的需求去連接客戶所需要的真正的數據源，即提供動態切換數據源的功能，那麽問題就解決了。那麽我們怎麽做呢？去修改那些我們要使用的dataSource源碼嗎？這顯然不是壹個好的方案，我們希望我們的修改與原dataSource代碼是分離的。根據以上的分析，使用GoF設計模式中的Decorator模式（裝飾者模式）應當是我們可以選擇的最佳方案。
什麽是“Decorator模式”？簡單點兒說就是當我們需要修改原有的功能，但我們又不願直接去修改原有的代碼時，設計壹個Decorator套在原有代碼外面。當我們使用Decorator的時候與原類完全壹樣，當Decorator的某些功能卻已經修改為了我們需要修改的功能。Decorator模式的結構如圖。
我們本來需要修改圖中所有具體的Component類的壹些功能，但卻並不是去直接修改它們的代碼，而是在它們的外面增加壹個Decorator。Decorator與具體的Component類都是繼承的AbstractComponent，因此它長得和具體的Component類壹樣，也就是說我們在使用Decorator的時候就如同在使用ConcreteComponentA或者ConcreteComponentB壹樣，甚至那些使用ConcreteComponentA或者ConcreteComponentB的客戶程序都不知道它們用的類已經改為了Decorator，但是Decorator已經對具體的Component類的部分方法進行了修改，執行這些方法的結果已經不同了。