我有一个J2EE webapp，用于上传文件，然后由数据库程序处理。因为我们不希望webapp必须等到数据库过程完成，所以它在不同的线程中执行。
在单独的线程中运行的进程需要获取并关闭自己的连接。 Web应用程序通常使用ServiceLocator查找数据源jndi名称，ServiceLocator从应用程序上下文查找它（jndi名称的查找键被定义为类常量）但是对于使用ServiceLocator查找jndi名称的单独线程失败。为了解决这个问题，我们使用jndi名称作为类常量，这样线程就可以直接查找数据源。
这意味着数据源的jndi名称现在已为应用程序修复，我们不能再在同一容器中部署相同的应用程序，而只需修改web.xml就可以使用不同的数据源。
围绕此行业最佳做法是什么？ jndi名称应该是可配置的还是可以为应用程序修复它？有没有人实现了可配置的数据源jndi名称解决方案，该解决方案既可用于webapp，也可用于容器中的其他线程？
答案 0 :(得分：2)
对于最佳实践，The role of JNDI in J2EE（由Kirk Pepperdine合着）是我发现的最好的文章之一。它清楚地解释了Sun关于开发，包装，部署以及JNDI如何适应的“愿景”。
简短版本是Sun和应用程序服务器提供商提供了一种定义和命名全局资源（java：DefaultDS）并绑定本地资源引用名称的方法（jdbc / mydatasource）到命名资源。
这解决了应用程序（由J2EE组件构成）的可移植性问题。但是本地资源引用名称是特定于组件的，因此它不能解决您的问题（多次部署相同的组件，但具有不同的本地资源引用名称）。
换句话说，Sun的愿景并未解决您的特定用例（尽管我认为这是一个有效的用例）。使用Sun模型，您应该在构建/打包时解决此问题（即创建和组装组件的两个版本，每个版本使用特定的本地资源引用名称）。
您描述的编程方法（从存储在JDNI / properties /中的密钥中查找值）是一种解决方法。
答案 1 :(得分：1)
您可以将JNDI名称或DataSource作为线程类的构造函数或方法参数传递。
答案 2 :(得分：1)
我认为尝试通过web.xml配置jndi是一个非常好的主意。我处理这个的方法是缓存数据源引用。 iow，在启动webapp时，引用的数据源是在线程可用时获取的，然后传递给任何其他需要它的对象，或者可供其他任何需要它的对象使用。