我有一个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密钥执行的值的查找）是一种解决方法。