我有一個J2EE Web應用程序，用於上傳文件，然後由數據庫過程處理。因爲我們不希望Web應用程序必須等待數據庫過程完成，它將在另一個線程中執行。應該通過ServiceLocator查找數據源的jndi名稱嗎？
在獨立線程中運行的進程需要獲取並關閉自己的連接。 Web應用程序通常使用ServiceLocator查找數據源jndi名稱，該ServiceLocator從應用程序上下文中查找它（jndi名稱的查找鍵被定義爲類常量），但對於使用ServiceLocator查找jndi名稱的單獨線程失敗。爲了解決這個問題，我們使用jndi名稱作爲類常量，以便線程可以直接查找數據源。
這意味着對數據源的JNDI名稱現在是固定的應用程序，我們可以簡單地通過修改web.xml不再部署在同一個容器，但不同的數據源相同的應用程序。
什麼是行業最佳實踐？ jndi的名字應該是可配置的還是可以修復它的應用程序？是否有人實現了一個可配置的數據源jndi名稱解決方案，它既可以在web應用程序中使用，也可以在容器中的其他線程中使用？
是的 - 我感到你的痛苦。
我認爲這是一個非常好的主意，試圖通過web.xml來配置jndi。我處理這個的方式緩存了數據源參考。喵，在webapp啓動時，引用的數據源被提供給線程，然後傳遞給任何其他需要它的對象。
您可以傳遞JNDI名稱或數據源作爲線程類的構造函數或方法參數。
對於最佳實踐，The role of JNDI in J2EE（由Kirk Pepperdine大學合着）是我已經找到了最好的文章之一。它清楚地解釋了Sun關於開發，打包，部署以及JNDI如何適應的「遠景」。
短的版本是，Sun和應用服務器提供商提供了一種方法來定義和命名全球資源（java的：DefaultDS的），並於當地資源參考名稱（JDBC/mydatasource）綁定到命名的資源。
這解決了應用程序的可移植性問題（由J2EE組件構成）。但本地資源ref名稱是特定於組件的，因此它不能解決您的問題（多次部署相同的組件，但使用不同的本地資源ref名稱）。
換句話說，Sun的願景並未解決您的特定用例（儘管我認爲這是一個有效的用例）。使用Sun模型，您應該在構建/打包時解決這個問題（即創建和組裝兩個版本的組件，每個版本都使用特定的本地資源參考名稱）。
您所描述的編程方法（從/屬性/不管存儲在一個JDNI密鑰執行的值的查找）是一種解決方法。