| 
 |  | 
     All the ConnectionPoolDataSource and
     DataSource implementations can be stored
     in JNDI.  In the case of the nonpooling
     implementations, a new instance will be created every time the
     object is retrieved from JNDI, with the
     same settings as the instance that was stored.  For the
     pooling implementations, the same instance will be retrieved
     as long as it is available (e.g., not a different
     JVM retrieving the pool from
     JNDI), or a new instance with the same
     settings created otherwise.
    
     In the application server environment, typically the
     application server's DataSource instance
     will be stored in JNDI, instead of the
     PostgreSQL™
     ConnectionPoolDataSource implementation.
    
     In an application environment, the application may store
     the DataSource in JNDI
     so that it doesn't have to make a reference to the
     DataSource available to all application
     components that may need to use it.  An example of this is
     shown in Example 11.2, “DataSource JNDI Code Example”.
    
Example 11.2. DataSource JNDI Code Example
     Application code to initialize a pooling DataSource and add
     it to JNDI might look like this:
PGPoolingDataSource source = new PGPoolingDataSource();
source.setDataSourceName("A Data Source");
source.setServerName("localhost");
source.setDatabaseName("test");
source.setUser("testuser");
source.setPassword("testpassword");
source.setMaxConnections(10);
new InitialContext().rebind("DataSource", source);
      Then code to use a connection from the pool might look
      like this:
Connection conn = null;
try {
    DataSource source = (DataSource)new InitialContext().lookup("DataSource");
    conn = source.getConnection();
    // use connection
} catch (SQLException e) {
    // log error
} catch (NamingException e) {
    // DataSource wasn't found in JNDI
} finally {
    if (con != null) {
        try { conn.close(); } catch (SQLException e) {}
    }
}