java - ServiceLocator 是否应该查找数据源的 jndi 名称？

Question

我有一个 J2EE webapp，用于上传文件，然后由数据库过程处理该文件。因为我们不希望 webapp 必须等到数据库过程完成，所以它在不同的线程中执行。

运行在独立线程中的进程需要获取并关闭自己的连接。 Web 应用程序通常使用 ServiceLocator 查找数据源 jndi 名称，后者又从应用程序上下文中查找(jndi 名称的查找键定义为类常量)，但对于使用 ServiceLocator 查找 jndi 名称的单独线程失败。为了解决这个问题，我们使用 jndi 名称作为类常量，以便线程可以直接查找数据源。

这意味着数据源的 jndi 名称现在对于应用程序是固定的，我们不能再通过修改 web.xml 将相同的应用程序部署在同一容器中但具有不同的数据源。

围绕此问题的行业最佳做法是什么？ jndi 名称应该是可配置的还是可以为应用程序修复它？有没有人实现了一个可配置的数据源 jndi 名称解决方案，它既可以在 webapp 中使用，也可以被容器中的其他线程使用？

Answer 1

有关最佳实践，The role of JNDI in J2EE (由 Kirk Pepperdine 合着)是我找到的最好的文章之一。它清楚地解释了 Sun 关于开发、打包、部署以及 JNDI 如何融入其中的“愿景”。

简而言之，Sun 和应用服务器提供商提供了一种方法来定义和命名全局 资源 (java:DefaultDS) 并绑定(bind)本地 资源引用名(jdbc/mydatasource) 到命名资源。

这解决了应用程序(由 J2EE 组件构成)的可移植性问题。但是本地资源引用名称是特定于组件的，因此它不能解决您的问题(多次部署相同的组件，但具有不同的本地资源引用名称)。

换句话说，Sun 的愿景并未解决您的特定用例(尽管我认为这是一个有效的用例)。使用 Sun 模型，您应该在构建/打包时解决这个问题(即创建和组装组件的两个版本，每个版本都使用特定的本地资源引用名称)。

您描述的编程方法(从存储在 JDNI/properties/whatever 中的键中查找值)是一种解决方法。