You can use DataSources to have multiple applications share a common configuration for accessing a database. This is accomplished by having each application reference the same DataSource name.
By using DataSources, many applications can be changed from a central location. For example, if you change the name of a default library used by all your applications and you have used a single DataSource to obtain connections for all of them, you can update the name of the collection in that DataSource. All of your applications then start using the new default library.
When using DataSources to obtain connections for an application, you can use the native JDBC driver's built-in support for connection pooling. This support is provided as an implementation of the ConnectionPoolDataSource interface.
Pooling is accomplished by handing out "logical" Connection objects instead of physical Connection objects. A logical Connection object is a connection object that is returned by a pooled Connection object. Each logical connection object acts as a temporary handle to the physical connection represented by the pooled connection object. To the application, when the Connection object is returned, there is no noticeable difference between the two. The subtle difference comes when you call the close method on the Connection object. This call invalidates the logical connection and returns the physical connection to the pool where another application is able to use the physical connection. This technique lets many logical connection objects reuse a single physical connection.
Connection pooling is accomplished by creating a DataSource object that references a ConnectionPoolDataSource object. ConnectionPoolDataSource objects have properties that can be set for handling various aspects of pool maintenance.
Refer to the example on how to set up connection pooling with UDBDataSource and UDBConnectionPoolDataSource more details. You can also see the Java™ Naming and Directory Interface (JNDI) for details about the role JNDI plays in this example.
From the example, the link that binds the two DataSource objects together is the dataSourceName. The link tells the DataSource object to defer establishing connections to the ConnectionPoolDataSource object that manages pooling automatically.
There is no difference between an application that uses Connection pooling and one that does not. Therefore, pooling support can be added after the application code is complete, without making any changes to the application code.
Refer to Example: Test the performance of connection pooling for more details.
The following is output from running the previous program locally during development.
Start timing the non-pooling DataSource version... Time spent: 6410
Start timing the pooling version... Time spent: 282
Java program completed.
By default, a UDBConnectionPoolDataSource pools a single connection. If an application needs a connection several times and only needs one connection at a time, using UDBConnectionPoolDataSource is a perfect solution. If you need many simultaneous connections, you must configure your ConnectionPoolDataSource to match your needs and resources.