Connections

The following topics are addressed here:

• Transparent Pool Reconfiguration

• Disabling Pooling

• Associating Connections with Threads

• Custom Connection Validation

• Sharing Connections

• Marking Bad Connections

• Handling Invalid Connections

Transparent Pool Reconfiguration

When the properties or attributes of a JDBC connection pool are changed, the connection pool is destroyed and re-created. Normally, applications using the connection pool must be redeployed as a consequence. This restriction can be avoided by enabling transparent JDBC connection pool reconfiguration. When this feature is enabled, applications do not need to be redeployed. Instead, requests for a new connections are blocked until the reconfiguration operation completes. Connection requests from any in-flight transactions are served using the old pool configuration so as to complete the transaction. Then, connections are created using the pool's new configuration, and any blocked connection requests are served with connections from the re-created pool..

To enable transparent JDBC connection pool reconfiguration, set the dynamic-reconfiguration-wait-timeout-in-seconds property of the JDBC connection pool to a positive, nonzero value in one of the following ways:

• Add it as a property in the Edit JDBC Connection Pool Properties page in the Administration Console. For more information, click the Help button in the Administration Console.

• Specify it using the --property option in the create-jdbc-connection-pool subcommand. For more information, see create-jdbc-connection-pool(1).

• Set it using the set subcommand. For example:

  asadmin set resources.jdbc-connection-pool.pool-name.property.dynamic-reconfiguration-wait-timeout-in-seconds=15

This property specifies the time in seconds to wait for in-use connections to close and in-flight transactions to complete. Any connections in use or transaction in flight past this time must be retried.

Disabling Pooling

To disable connection pooling, set the Pooling attribute to false. The default is true. You can enable or disable connection pooling in one of the following ways:

• Enter a Pooling value in the Edit Connection Pool Advanced Attributes page in the Administration Console. For more information, click the Help button in the Administration Console.

• Specify the --pooling option in the asadmin create-jdbc-connection-pool command. For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

• Specify the pooling option in the asadmin set command. For example:

  asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.pooling=false

  For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

The pooling option and the system property com.sun.enterprise.connectors.SwitchoffACCConnectionPooling, which turns off connection pooling in the Application Client Container, do not affect each other.

An exception is thrown if associate-with-thread is set to true and pooling is disabled. An exception is thrown if you attempt to flush a connection pool when pooling is disabled. A warning is logged if the following attributes are used, because they are useful only in a pooled environment:

• connection-validation

• validate-atmost-once-period

• match-connections

• max-connection-usage

• idle-timeout

Associating Connections with Threads

To associate connections with a thread, set the Associate With Thread attribute to true. The default is false. A true setting allows connections to be saved as ThreadLocal in the calling thread. Connections get reclaimed only when the calling thread dies or when the calling thread is not in use and the pool has run out of connections. If the setting is false, the thread must obtain a connection from the pool each time the thread requires a connection.

The Associate With Thread attribute associates connections with a thread such that when the same thread is in need of connections, it can reuse the connections already associated with that thread. In this case, the overhead of getting connections from the pool is avoided. However, when this value is set to true, you should verify that the value of the Max Pool Size attribute is comparable to the Max Thread Pool Size attribute of the thread pool. If the Max Thread Pool Size value is much higher than the Max Pool Size value, a lot of time is spent associating connections with a new thread after dissociating them from an older one. Use this attribute in cases where the thread pool should reuse connections to avoid this overhead.

You can set the Associate With Thread attribute in the following ways:

• Enter an Associate With Thread value in the Edit Connection Pool Advanced Attributes page in the Administration Console. For more information, click the Help button in the Administration Console.

• Specify the --associatewiththread option in the asadmin create-jdbc-connection-pool command. For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

• Specify the associate-with-thread option in the asadmin set command. For example:

  asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.associate-with-thread=true

  For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

Custom Connection Validation

You can specify a custom implementation for Connection Validation that is faster or optimized for a specific database. Set the Validation Method attribute to the value custom-validation. (Other validation methods available are table (the default), auto-commit, and meta-data.) The GlassFish Server provides a public interface, org.glassfish.api.jdbc.ConnectionValidation, which you can implement to plug in your implementation. A new attribute, Validation Classname, specifies the fully qualified name of the class that implements the ConnectionValidation interface. The Validation Classname attribute is required if Connection Validation is enabled and Validation Method is set to Custom Validation.

To enable this feature, set Connection Validation, Validation Method, and Validation Classname for the JDBC connection pool in one of the following ways:

• Enter Connection Validation, Validation Method, and Validation Classname values in the Edit Connection Pool Advanced Attributes page in the Administration Console. You can select from among validation class names for common databases in the Validation Classname field. For more information, click the Help button in the Administration Console.

• Specify the --isconnectionvalidatereq, --validationmethod, and --validationclassname options in the asadmin create-jdbc-connection-pool command. For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

• Specify the is-connection-validation-required, connection-validation-method, and validation-classname options in the asadmin set command. For example:

  asadmin set domain1.resources.jdbc-connection-pool.MyPool.is-connection-validation-required=true
  asadmin set domain1.resources.jdbc-connection-pool.MyPool.connection-validation-method=custom-validation
  asadmin set domain1.resources.jdbc-connection-pool.MyPool.validation-classname=impl-class

  For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

By default, optimized validation mechanisms are provided for DB2, Java DB, MSSQL, MySQL, Oracle, PostgreSQL and Sybase databases. Additionally, for JDBC 4.0 compliant database drivers, a validation mechanism is provided that uses the Connection.isValid(0) implementation.

Sharing Connections

When multiple connections acquired by an application use the same JDBC resource, the connection pool provides connection sharing within the same transaction scope. For example, suppose Bean A starts a transaction and obtains a connection, then calls a method in Bean B. If Bean B acquires a connection to the same JDBC resource with the same sign-on information, and if Bean A completes the transaction, the connection can be shared.

Connections obtained through a resource are shared only if the resource reference declared by the Java EE component allows it to be shareable. This is specified in a component’s deployment descriptor by setting the res-sharing-scope element to Shareable for the particular resource reference. To turn off connection sharing, set res-sharing-scope to Unshareable.

For general information about connections and JDBC URLs, see Chapter 12, Administering Database Connectivity, in Oracle GlassFish Server 3.1 Administration Guide.

Marking Bad Connections

The DataSource implementation in the GlassFish Server provides a markConnectionAsBad method. A marked bad connection is removed from its connection pool when it is closed. The method signature is as follows:

public void markConnectionAsBad(java.sql.Connection con)

For example:

com.sun.appserv.jdbc.DataSource ds=
   (com.sun.appserv.jdbc.DataSource)context.lookup("dataSource");
Connection con = ds.getConnection();
Statement stmt = null;
try{
   stmt = con.createStatement();
   stmt.executeUpdate("Update");
}
catch (BadConnectionException e){
   ds.markConnectionAsBad(con) //marking it as bad for removal
}
finally{
   stmt.close();    
   con.close(); //Connection will be destroyed during close.
}

Handling Invalid Connections

If a ConnectionErrorOccured event occurs, the GlassFish Server considers the connection invalid and removes the connection from the connection pool. Typically, a JDBC driver generates a ConnectionErrorOccured event when it finds a ManagedConnection object unusable. Reasons can be database failure, network failure with the database, fatal problems with the connection pool, and so on.

If the fail-all-connections setting in the connection pool configuration is set to true, and a single connection fails, all connections are closed and recreated. If this setting is false, individual connections are recreated only when they are used. The default is false.

The is-connection-validation-required setting specifies whether connections have to be validated before being given to the application. If a resource’s validation fails, it is destroyed, and a new resource is created and returned. The default is false.

The prefer-validate-over-recreate property specifies that validating idle connections is preferable to closing them. This property has no effect on non-idle connections. If set to true, idle connections are validated during pool resizing, and only those found to be invalid are destroyed and recreated. If false, all idle connections are destroyed and recreated during pool resizing. The default is false.

You can set the fail-all-connections, is-connection-validation-required, and prefer-validate-over-recreate configuration settings during creation of a JDBC connection pool. Or, you can use the asadmin set command to dynamically reconfigure a setting. For example:

asadmin set server.resources.jdbc-connection-pool.JCPool1.fail-all-connections="true"
asadmin set server.resources.jdbc-connection-pool.JCPool1.is-connection-validation-required="true"
asadmin set server.resources.jdbc-connection-pool.JCPool1.property.prefer-validate-over-recreate="true"

For details, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

The interface ValidatingManagedConnectionFactory exposes the method getInvalidConnections to allow retrieval of the invalid connections. The GlassFish Server checks if the JDBC driver implements this interface, and if it does, invalid connections are removed when the connection pool is resized.