What has data source and connection pooling in Tomcat, and other containers, has to do with JNDI?

Question

I am trying to understand connection pooling (JDBC connection pooling). According to the answer in this question every container has its own mechanism. I'm also trying to understand JNDI and its implementations and whatever post or article are there it is related to locating objects in network like directories and users and here are some articles:

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

Reading this article that describes how to manage a connection pooling in Tomcat container, second paragraph

javax.sql.DataSource interface is registered with the naming service based on JNDI API. A data source driver allows accessed to the database via DataSource interface. A DataSource object is looked up in the context based on registered through JNDI Resource

The question is what JNDI and networking directories has to do with instantiating an implementation of DataSource that provides a connection pooling, probably implemented via flyweight design pattern ?

Am I missing something ?

Answer 1

They are not directly related. DataSource is just an interface for managing connections in a database connection pool. Any Java Servlet Container or Java EE Container can provide its own implementation for this interface.

As an application developer you do not need to worry about how the container instantiates this implementation or what the actual implementation class is.

To provide loose coupling between the actual container implementation and your application, you just need to get an instance of this implementation which is typically done through JNDI.

The container instantiates the DataSource implementation and binds it to a specific address in the JNDI registry where you can retrieve it as an application developer. In the application, you just use the DataSource interface for accessing this implementation thus making your application portable over different servers and their respective DataSource implementations.

Answer 2

To imagine how these completely unrelated technologies work, it is probably best to illustrate why things like JNDI, Pooling even exist.

1. You have a Java application and you'd like to connect to database and persist your data. Ok, here comes JDBC.

2. When you're persisting your data, you notice that opening and closing a connection to database is time consuming and slows your program down. So you introduce pooling - JDBC connections are not opened and closed every time they're used, but taken from and returned to a pool instead.

   3. JPA - You're sick and tired of writing database-specific code, so you write a library to handle many persistence-related things for you so your life is easier.

   4. JNDI - You're writing your Java application in a form of an enterprise application, be it Java EE or it's kind-of deprecated alternative Spring. And you have to create somehow. Naive approach is for the application to create it's own datasource (in Spring still viable option). A better approach is to configure the datasource on the server. The datasource is identified by a name and the application only specifies the name - nothing else. The datasource is then injected to the application when it is deployed to the application server. The datasource configuration and creation is done on the server and injected into the application via JNDI. This way, for example, you can have more applications sharing the same datasource with the same connection pool.

But JNDI doesn't only serve for datasource "injection". With JNDI, you can identify and localize any resources.

Answer 3

Sometimes JNDI is used as an objects store(Java objects), not to access objects over a network or a file system, such as printers and directories, but to access Java objects that have already been instantiated in the memory. The confusion that I had is due to the fact that whenever you read about JNDI, it explain its main purpose not the way it is used to instantiate DataSource objects:

Here is this quot from oracle tutorial :

The Directory as an Object Store In addition to using the directory in the traditional way, Java applications can also use it as a repository for Java objects, that is to store and retrieve Java objects. For example, a Java print client program should be able to look up a printer object from the directory and send a data stream to the printer object for printing.

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