In this chapter, you will learn how to make database connections using JDBC's DataSource object. The purpose of this chapter is to provide snippets, reusable code samples, and methods that deal with the Connection objects using the javax.sql.DataSource interface. When writing this chapter, I relied on JDK 1.4 and the final release of the JDBC 3.0 specification.

This chapter's focus will be on answering the following question: how do you obtain a java.sql.Connection object from javax.sql.DataSource objects? I can present this question in another way: what are the connection options? This chapter will answer these questions, and for each case I will provide working code.

To select data from tables/views, update columns in tables, create a new table in a database, or do anything useful with any database, you need a database connection (in JDBC, this is called java.sql.Connection). Typically, database access in any environment starts with the connection.

4-1.How Do You Create Connection Using a DataSource Object?

DataSource (defined in the javax.sql package) is an abstraction layer for Java database applications. Database applications may use a JNDI context to find DataSource attributes that are configured on the deployment server. You can obtain a DataSource object in two ways:

• Using JNDI
• Without using JNDI

JNDI is an API for accessing different kinds of naming and directory services. JNDI is not specific to a particular naming or directory service; it can be used to access many different kinds of systems including file systems, Common Object Request Broker Architecture (CORBA), Java Remote Method Invocation (RMI), and Enterprise JavaBeans (EJB), as well as directory services such as Lightweight Directory Access Protocol (LDAP) and Network Information Service (NIS). Although you can use JDBC to access a set of relational databases, you can use JNDI to access a set of naming and directory services.

You will look at both of these options in this chapter. From a portability point of view, obtaining a DataSource interface using JNDI is more portable than not using JNDI, according to http://java.sun.com/products/jdbc/articles/package2.html:

The DataSource interface provides an alternative to the DriverManager class for making a connection to a data source. Using a DataSource implementation is better for two important reasons: it makes code more portable, and it makes code easier to maintain. A DataSource object represents a real-world data source. Depending on how it is implemented, the data source can be anything from a relational database to a spreadsheet or a file in tabular format.When a DataSource object has been registered with a JNDI naming service, an application can retrieve it from the naming service and use it to make a connection to the data source it represents.

The following snippet shows how to retrieve the DataSource object associated with the logical name jdbc/InventoryDB and then use it to get a connection. The first two lines use the JNDI API to get the DataSource object; the third line uses JDBC API to get the connection.

Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/InventoryDB");
Connection con = ds.getConnection("myUserName", "myPassword");

The JDK 1.4 documentation defines javax.sql.DataSource as follows:

A factory for connections to the physical data source that this DataSource object represents. An alternative to the DriverManager facility, a DataSource object is the preferred means of getting a connection. An object that implements the DataSource interface will typically be registered with a naming service based on the JNDI API.

The DataSource interface is implemented by a driver vendor. Three types of implementations exist:

• Basic implementation: Produces a standard Connection object.
• Connection pooling implementation: Produces a Connection object that will automatically participate in connection pooling. This implementation works with a middle-tier connection pooling manager.
• Distributed transaction implementation: Produces a Connection object that may be used for distributed transactions and almost always participates in connection pooling. This implementation works with a middle-tier transaction manager and almost always with a connection pooling manager.

A DataSource object has properties that you can modify when necessary. For example, if the data source moves to a different server, you can change the property for the server. The benefit is that because the data source's properties can be changed, any code accessing that data source does not need to be changed.

A driver that is accessed via a DataSource object does not register itself with the DriverManager facility. Rather, a DataSource object is retrieved through a lookup operation and then used to create a Connection object. With a basic implementation, the connection obtained through a DataSource object is identical to a connection obtained through the DriverManager facility.