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

Question

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

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

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

在这方面有哪些行业最佳做法？ jndi 名称应该是可配置的，还是可以为应用程序修复它？有没有人实现了一个可配置的数据源 jndi 名称解决方案，该解决方案既可用于 webapp，也可用于容器中的其他线程？

Answer 1

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

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

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

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

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

Answer 2

是的 - 我感觉到你的痛苦。

我确实认为尝试通过 web.xml 使 jndi 可配置是一个非常好的主意。我处理这个的方式是缓存数据源引用。 iow，在 webapp 启动时，引用的数据源是在线程可用时获取的，然后传递给需要它的任何其他对象或使其可用。

Answer 3

您可以将 JNDI 名称或 DataSource 作为线程类的构造函数或方法参数传入。