3

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 ?

Community
  • 1
  • 1
Adelin
  • 18,144
  • 26
  • 115
  • 175

3 Answers3

2

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.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Coffee Monkey
  • 481
  • 2
  • 7
  • But isn't JNDI used to locate directories and object a cross the notwork how does the container provide DataSource implementation to the application with JNDI ? – Adelin Mar 12 '16 at 12:59
  • 1
    JNDI is used to make object references available. This can be local or over a network, depending on the JNDI implementation. In the context of container DataSources, the container simply does an object instantiation (i.e. new DataSourceImpl()) and then "registers" it in the JNDI registry. The application can then use JNDI to lookup this DataSource. – Coffee Monkey Mar 14 '16 at 06:35
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.

    1. 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.

    2. 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.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Pavel Pscheidl
  • 334
  • 3
  • 11
  • From what I understand the point is the expose data source via JNDI so that more than one application can use the same pool ? – Adelin Mar 13 '16 at 11:20
  • @Adelin - `more than one application can use the same pool` - No, that's not the primary reason. The primary reason is to have a *single location* where a data source can be defined, such that the rest of the code is unaware of that definition. The rest of the code can be a single app (preferred) or multiple apps (not preferred). – Arjan Tijms Mar 13 '16 at 11:53
  • @Paulie "Naive approach is for the application to create it's own datasource" - It's not necessarily naive. It depends on the application. See http://stackoverflow.com/a/16261491/472792. The beauty of Java EE is that you can transparently move back and forth from in-app defined data source to "on the server" defined data source, without the application code using that source knowing or caring. – Arjan Tijms Mar 13 '16 at 11:55
  • @ArjanTijms But why JNDI ? Why not using some jar that exposes say a factory of Datasources or some that it manages and every application can acquire datasoure when needed ? – Adelin Mar 13 '16 at 11:57
  • @Adelin because JNDI for a long time had been the default directory for looking up "things". It's the universal factory so to speak. The factory you speak of, which interface would that one have needed to expose? How would one look up that factory? What would be the (optional) XML format from which this factory of yours would read its config? And what arguments would you use to persuade key other developers that your factory design is the best? In short the reason why it's not there is that nobody (for instance, you) pushed this issue and volunteered to spec it and implement it. – Arjan Tijms Mar 13 '16 at 12:46
  • @Adelin - There is one standardized "factory" - and that is JNDI. But you should view JNDI as a lookup table, rather than a factory. – Pavel Pscheidl Mar 13 '16 at 17:56
  • @ArjanTijms Ok, maybe not naive, but this approach works well - you can transfer your archives across many servers and leave the configuration to the server administrator. I see little point in local environment definition - the database still has to be defined somewhere. But this is probably different topic. – Pavel Pscheidl Mar 13 '16 at 17:59
  • @Paulie For some applications/use cases there is no server administrator, so you can't leave the configuration to that person ;) Also, there doesn't have to be an external database. The "database" can be fully internal as an embedded database, perhaps just to temporarily store some simple values. If an application is allowed to use say an internal HashMap to store things, or an embedded cache (like InfiniSpan), without the need of a server administrator, then why not a small and simple embedded DB? Java EE needs to scale both up and down. One's best practice is not everyone's best practice ;) – Arjan Tijms Mar 15 '16 at 00:01
1

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

Adelin
  • 18,144
  • 26
  • 115
  • 175