什么是更快：JDBC还是JNDI？

Question

我有两个选项来配置我的应用程序数据库连接 - 一个使用JDBC，另一个使用JNDI。就这些连接类型与数据库的工作速度而言，最佳选择是什么。

我理解这些是使用不同原则的两种不同类型的数据库连接（JDBC是直接数据库连接，JNDI是应用程序服务器端的数据库连接池配置）。但是否有其他一般的JDBC / JNDI优缺点可能比运行速度更重要？如果是的话，他们是什么？

Answer 1

数据库连接始终使用JDBC。使用JNDI，您可以在目录服务中注册数据源，该服务可以通过其名称进行查找。因此，JDBC和JNDI完全不同，不可互换。

Answer 2

我打赌你的意思是选择

1. 在您的应用程序中手动创建数据源或jdbc连接，或
2. 在容器中设置数据源，应用程序通过JNDI
查找数据源

如果是这种情况，请尽可能坚持2。

选择的主要原因绝不是性能差异。在大多数情况下，坚持2的原因是，您需要2来从容器中获取更多高级功能，例如，分布式事务。

Answer 3

这是我发现的关于JNDI和JDBC的内容。

JNDI：这是一种类似于电话目录的技术，用于远程搜索服务器和数据源上的名称。

JNDI创建一个连接池。连接池是服务器上的一个环境，其中JNDI和数据库封装为Type4连接。

JDBC：使Java程序能够执行SQL语句的Java API。 这允许Java程序与任何符合SQL的数据库进行交互。

JDBC类似于ODBC，但是专门为Java程序设计，而ODBC是与语言无关的。

JDBC由Sun Microsystems开发。 JNDI更快更有效。

Answer 4

在这个问题上并不完全清楚。

JNDI不是一种数据库连接。您可以使用JNDI查找DataSource，这是一个连接工厂。 DataSource是JDBC API的一部分，因此JNDI使用JDBC而不是替代方法。

您是在谈论针对数据库使用JDBC获取目录信息，而不是针对LDAP存储库使用JNDI？

Answer 5

真正的速度优势来自于能够重用数据库连接。

因此，您需要使用提供数据库连接池的方法，然后使用适当的技术进入池。根据实现，这可以是JDBC（如果驱动程序本身支持它）或JNDI或完全不同的东西。

如果您的应用程序在Web容器内运行，则通常使用JNDI来允许在Web容器中而不是在应用程序内部配置和管理池。

Answer 6

如前面的答案所述，使用Datasource与在技术方面使用JDBC相同。

尽管如此，使用数据源通常是首选方式，因为这样您就可以让服务器管理数据库连接池。

Answer 7

是否使用连接池不会影响应用程序代码。它不需要对应用程序进行任何代码更改，因为应用程序会对先前注册的数据源的JNDI名称执行查找。如果数据源在JNDI注册期间指定了连接池实现（如Creating a Data Source Using the DataDirect Connection Pool Manager部分所述），则客户端应用程序可通过连接池实现更快的连接。

Answer 8

这个问题毫无意义。更快的是什么？没有什么可比的。 JDBC是关系数据库的通用接口。 JNDI是命名系统的通用接口。很有可能的是，任何一方的效率都取决于与之通信的目标系统的99％。在任何情况下，关系数据库和命名系统都能满足完全不同的需求，而这些需求在很大程通常JNDI用于获取连接，然后使用JDBC来操作该连接。