Java Tutorial - Java Script :
Connections, DataSources, JNDI, and Pooling
As JDBC evolved, the awkwardness of using the previously demonstrated means for obtaining connections in server-side programs became more apparent. The previous connection process requires registering a specific driver class by name at run time. It also requires driver-specific URL strings. Furthermore, the URL strings are often specific to a particular installation because database resources may be located on differing machines using different connection parameters throughout an organization. Every program written this way needs a means to manage and modify the connection information. JDBC 2.0 addressed many of these concerns by introducing the concept of the DataSource. ADataSource is a factory for creating database connections. By a factory we mean that a DataSource is an implementation of the factory design pattern. A DataSource is an implementation of the javax.sql.DataSource interface. The vendor (creator) of the JDBC driver normally implements DataSources specifically for the driver and provides it as part of the driver. The properties of a DataSource object can be modified as needed. If a database is moved to another server (or if you want to use a different database for testing for example), the properties specific to that DataSource can be changed. Any code accessing the DataSource does not need to be changed.
There are three types of DataSource implementations
· A Basic implementation provides a standard connection.
· A Connection Pooling implementation that provides a connection from a cache or pool of connections. This will be discussed in more detail later in this section.
· A Distributed Transaction implementation, which creates a connection suitable for distributed transactions.
DataSources are designed for use with the Java Naming and Directory Interface (JNDI). The DataSource is configured within the JNDI provider and bound to a JNDI name. The code for getting a database connection from a DataSource normally looks similar to the following:
Context ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup(“jdbc/TestDataSource”);
Connection con = ds.getConnection(“sa”, “”);
This gets a connection just as in the previous example that did not use a DataSource; however, in this case, the Java program is not required to know any of the specifics of the database other than the user ID and password. Everything else has been configured in JNDI. Each DataSource configured in JNDI represents a database that can be accessed by the program. (We will cover configuring DataSources later in the chapter). The lookup method of the context retrieves a resource by looking up the name bound to the resource. JNDI supports a hierarchical structure to names similar to a file system. In this case the name is TestDataSource. By convention, the name is contained in the “jdbc” subcontext of JNDI. A subcontext is like a folder in a file system. The jdbc subcontext is normally found immediately below the JNDI root context. The resource returned by the lookup method is a generic object that must be converted or cast as the DataSource interface so that it can be used. After the DataSource has been retrieved, the program can get a database connection from the DataSource interface. The pooled DataSource is another type of DataSource implementation. A pooled DataSource stores connections in a pool. A pool is similar to a cache.
Unlike a cache, however, a pool is normally prepopulated with a number of items. The items are handed out from the pool when requested. If there are no longer any items available in the pool, then either the pool adds more items or it fails. In the case of DataSources, connections are handed out from a pool of premade connections. This represents a significant performance increase when databases connections are needed frequently by several threads or processes. For example, in a servlet environment, a servlet can request a connection from a pool (often managed by the servlet container) instead of directly opening the database connection. The pool is initialized and connections made when the servlet container starts. This makes connections instantly available to servlets that need them. Closing the connection automatically restores the connection to the pool.
The connection itself is not normally closed, but remains open for the next time a connection is needed from the pool.
Beyond SQL Entry-Level Commands
JDBC also requires support for certain nonstandard extensions beyond those supported by the minimal ANSI standard. In order to use these extensions, JDBC defines a standard “escape” clause that is used to provide information directly to the JDBC driver. The driver uses this information to build the database- specific command. The syntax for the escape is: {keyword ... parameters ... } where keyword is the name of the command or function, and the parameters are specific to the specific command.
