Part I Development Tasks and Tools
1. Setting Up a Development Environment
Part II Developing Applications and Application Components
6. Using the Java Persistence API
7. Developing Web Applications
8. Using Enterprise JavaBeans Technology
9. Using Container-Managed Persistence
12. Developing Lifecycle Listeners
13. Developing OSGi-enabled Java EE Applications
Part III Using Services and APIs
14. Using the JDBC API for Database Access
Transparent Pool Reconfiguration
Associating Connections with Threads
Obtaining a Physical Connection From a Wrapped Connection
Using the Connection.unwrap() Method
Allowing Non-Component Callers
Using Application-Scoped Resources
Restrictions and Optimizations
Disabling Stored Procedure Creation on Sybase
15. Using the Transaction Service
16. Using the Java Naming and Directory Interface
The following topics are addressed here:
You can specify a statement that executes each time a physical connection to the database is created (not reused) from a JDBC connection pool. This is useful for setting request or session specific properties and is suited for homogeneous requests in a single application. Set the Init SQL attribute of the JDBC connection pool to the SQL string to be executed in one of the following ways:
Enter an Init SQL 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 --initsql 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 init-sql option in the asadmin set command. For example:
asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.init-sql="sql-string"
For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.
An abnormally long running JDBC query executed by an application may leave it in a hanging state unless a timeout is explicitly set on the statement. Setting a statement timeout guarantees that all queries automatically time out if not completed within the specified period. When statements are created, the queryTimeout is set according to the statement timeout setting. This works only when the underlying JDBC driver supports queryTimeout for Statement, PreparedStatement, CallableStatement, and ResultSet.
You can specify a statement timeout in the following ways:
Enter a Statement Timeout 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 --statementtimeout option in the asadmin create-jdbc-connection-pool command. For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.
If statements are not closed by an application after use, it is possible for the application to run out of cursors. Enabling statement leak detection causes statements to be considered as leaked if they are not closed within a specified period. Additionally, leaked statements can reclaimed automatically.
To enable statement leak detection, set Statement Leak Timeout In Seconds for the JDBC connection pool to a positive, nonzero value in one of the following ways:
Specify the --statementleaktimeout option in the create-jdbc-connection-pool subcommand. For more information, see create-jdbc-connection-pool(1).
Specify the statement-leak-timeout-in-seconds option in the set subcommand. For example:
asadmin set resources.jdbc-connection-pool.pool-name.statement-leak-timeout-in-seconds=300
When selecting a value for Statement Leak Timeout In Seconds, make sure that:
It is less than the Connection Leak Timeout; otherwise, the connection could be closed before the statement leak is recognized.
It is greater than the Statement Timeout; otherwise, a long running query could be mistaken as a statement leak.
After enabling statement leak detection, enable leaked statement reclamation by setting Reclaim Leaked Statements for the JDBC connection pool to a true value in one of the following ways:
Specify the --statementleakreclaim=true option in the create-jdbc-connection-pool subcommand. For more information, see create-jdbc-connection-pool(1).
Specify the statement-leak-reclaim option in the set subcommand. For example:
asadmin set resources.jdbc-connection-pool.pool-name.statement-leak-reclaim=true
Statement caching stores statements, prepared statements, and callable statements that are executed repeatedly by applications in a cache, thereby improving performance. Instead of the statement being prepared each time, the cache is searched for a match. The overhead of parsing and creating new statements each time is eliminated.
Statement caching is usually a feature of the JDBC driver. The GlassFish Server provides caching for drivers that do not support caching. To enable this feature, set the Statement Cache Size for the JDBC connection pool in one of the following ways:
Enter a Statement Cache Size 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 --statementcachesize 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 statement-cache-size option in the asadmin set command. For example:
asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.statement-cache-size=10
For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.
By default, this attribute is set to zero and the statement caching is turned off. To enable statement caching, you can set any positive nonzero value. The built-in cache eviction strategy is LRU-based (Least Recently Used). When a connection pool is flushed, the connections in the statement cache are recreated.
You can trace the SQL statements executed by applications that use a JDBC connection pool. Set the SQL Trace Listeners attribute to a comma-separated list of trace listener implementation classes in one of the following ways:
Enter an SQL Trace Listeners 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 --sqltracelisteners 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 sql-trace-listeners option in the asadmin set command. For example:
asadmin set domain1.resources.jdbc-connection-pool.DerbyPool.sql-trace-listeners=listeners
For more information, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.
The GlassFish Server provides a public interface, org.glassfish.api.jdbc.SQLTraceListener, that implements a means of recording SQLTraceRecord objects. To make custom implementations of this interface available to the GlassFish Server, place the implementation classes in as-install/lib.
The GlassFish Server provides an SQL tracing logger to log the SQL operations in the form of SQLTraceRecord objects in the server.log file. The module name under which the SQL operation is logged is javax.enterprise.resource.sqltrace. SQL traces are logged as FINE messages along with the module name to enable easy filtering of the SQL logs. A sample SQL trace record looks like this:
[#|2009-11-27T15:46:52.202+0530|FINE|glassfishv3.0|javax.enterprise.resource.sqltrace.com.sun.gjc.util |_ThreadID=29;_ThreadName=Thread-1;ClassName=com.sun.gjc.util.SQLTraceLogger;MethodName=sqlTrace; |ThreadID=77 | ThreadName=p: thread-pool-1; w: 6 | TimeStamp=1259317012202 | ClassName=com.sun.gjc.spi.jdbc40.PreparedStatementWrapper40 | MethodName=executeUpdate | arg[0]=insert into table1(colName) values(100) | arg[1]=columnNames | |#]
This trace shows that an executeUpdate(String sql, String columnNames) operation is being done.
When SQL statement tracing is enabled and JDBC connection pool monitoring is enabled, GlassFish Server maintains a tracing cache of recent queries and their frequency of use. The following JDBC connection pool properties can be configured to control this cache and the monitoring statistics available from it:
Specifies how long in minutes to keep a query in the tracing cache, tracking its frequency of use. The default value is 5 minutes.
Specifies how many of the most used queries, in frequency order, are listed the monitoring report. The default value is 10 queries.
Set these parameters in one of the following ways:
Add them as properties in the Edit JDBC Connection Pool Properties page in the Administration Console. For more information, click the Help button in the Administration Console.
Specify them using the --property option in the create-jdbc-connection-pool subcommand. For more information, see create-jdbc-connection-pool(1).
Set them using the set subcommand. For example:
asadmin set resources.jdbc-connection-pool.pool-name.property.time-to-keep-queries-in-minutes=10