Tomcat 和其他容器中的数据源和连接池与 JNDI 有什么关系？答案

【问题标题】：What has data source and connection pooling in Tomcat, and other containers, has to do with JNDI?Tomcat 和其他容器中的数据源和连接池与 JNDI 有什么关系？
【发布时间】：2016-06-27 14:29:14
【问题描述】：

我正在尝试了解连接池（JDBC 连接池）。根据答案 in this question 每个容器都有自己的机制。我也在尝试了解 JNDI 及其实现，以及与在网络中定位对象（如目录和用户）相关的任何帖子或文章，这里有一些文章：

http://www.oracle.com/technetwork/java/jndi/index.html http://www.oracle.com/technetwork/java/overview-142035.html

阅读这篇描述如何在 Tomcat 容器中管理连接池的文章，第二段

javax.sql.DataSource 接口注册到命名服务基于 JNDI API。数据源驱动程序允许访问数据库通过 DataSource 接口。在中查找 DataSource 对象基于通过JNDI Resource注册的上下文

问题是 JNDI 和网络目录与实例化提供连接池的 DataSource 实现有什么关系，可能通过享元设计模式实现？

我错过了什么吗？

【问题讨论】：

标签： java jdbc jndi connection-pooling

【解决方案1】：

它们没有直接关系。 DataSource 只是一个用于管理数据库连接池中的连接的接口。任何 Java Servlet Container 或 Java EE Container 都可以为此接口提供自己的实现。

作为应用程序开发人员，您无需担心容器如何实例化此实现或实际的实现类是什么。

要在实际容器实现和您的应用程序之间提供松散耦合，您只需要获取此实现的一个实例，该实例通常通过 JNDI 完成。

容器实例化 DataSource 实现并将其绑定到 JNDI 注册表中的特定地址，您可以在其中作为应用程序开发人员检索它。在应用程序中，您只需使用 DataSource 接口来访问此实现，从而使您的应用程序可移植到不同的服务器及其各自的 DataSource 实现。

【讨论】：

但是JNDI不是用来定位目录和对象的吗？容器如何通过JNDI向应用程序提供DataSource实现？
JNDI 用于使对象引用可用。这可以是本地的，也可以是网络上的，具体取决于 JNDI 实现。在容器数据源的上下文中，容器只是简单地进行对象实例化（即 new DataSourceImpl()），然后在 JNDI 注册表中“注册”它。然后应用程序可以使用 JNDI 来查找这个 DataSource。

【解决方案2】：

要想象这些完全不相关的技术是如何工作的，最好说明为什么会存在 JNDI、Pooling 之类的东西。

您有一个 Java 应用程序，并且想要连接到数据库并保存您的数据。好的，JDBC 来了。
在持久化数据时，您会注意到打开和关闭与数据库的连接非常耗时，并且会减慢您的程序速度。因此，您引入了池 - JDBC 连接不会在每次使用时打开和关闭，而是从池中取出并返回到池中。
1. JPA - 您厌倦了编写特定于数据库的代码，因此您编写了一个库来为您处理许多与持久性相关的事情，这样您的生活会更轻松。
2. JNDI - 您正在以企业应用程序的形式编写 Java 应用程序，无论是 Java EE 还是某种已弃用的替代 Spring。你必须以某种方式创造。天真的方法是让应用程序创建它自己的数据源（在 Spring 中仍然可行的选项）。更好的方法是在服务器上配置数据源。数据源由名称标识，应用程序仅指定名称 - 没有别的。然后在将数据源部署到应用程序服务器时将其注入到应用程序中。数据源配置和创建在服务器上完成，并通过 JNDI 注入到应用程序中。例如，通过这种方式，您可以让更多应用程序使用同一个连接池共享同一个数据源。

但是 JNDI 不仅仅服务于数据源“注入”。使用 JNDI，您可以识别和本地化任何资源。

【讨论】：

据我了解，重点是通过 JNDI 公开数据源，以便多个应用程序可以使用同一个池？
@Adelin - more than one application can use the same pool - 不，这不是主要原因。主要原因是有一个可以定义数据源的单个位置，这样代码的其余部分就不会知道该定义。其余代码可以是单个应用（首选）或多个应用（非首选）。
@Paulie “天真的方法是让应用程序创建它自己的数据源” - 这不一定是天真的。这取决于应用程序。见stackoverflow.com/a/16261491/472792。 Java EE 的美妙之处在于，您可以透明地从应用内定义的数据源到“服务器上”定义的数据源来回移动，而无需知道或关心使用该源的应用程序代码。
@ArjanTijms 但是为什么是 JNDI 呢？为什么不使用一些 jar 来公开数据源工厂或它管理的一些工厂，并且每个应用程序都可以在需要时获取数据源？
@Adelin 因为 JNDI 长期以来一直是查找“事物”的默认目录。可以说是通用工厂。你说的工厂，需要暴露哪个接口？怎么看那家工厂？您的这个工厂将从中读取其配置的（可选）XML 格式是什么？你会用什么论据来说服其他关键开发人员你的工厂设计是最好的？简而言之，它不存在的原因是没有人（例如，您）推动这个问题并自愿规范并实施它。

【解决方案3】：

有时 JNDI 用作对象存储（Java 对象），不是通过网络或文件系统访问对象，例如打印机和目录，而是访问已经在内存中实例化的 Java 对象。我之所以感到困惑，是因为每当您阅读 JNDI 时，它都会解释其主要用途，而不是用于实例化 DataSource 对象的方式：

这是来自 oracle 教程的引用：

目录作为对象存储除了使用目录传统方式，Java 应用程序也可以将其用作存储库对于 Java 对象，即存储和检索 Java 对象。为了例如，Java 打印客户端程序应该能够查找目录中的打印机对象并将数据流发送到用于打印的打印机对象。

http://docs.oracle.com/javase/jndi/tutorial/getStarted/concepts/java.html

【讨论】：