| Connectors, Connection Pool, JDBC features in GlassFish Server Open Source Edition 3.1 1.2. Name(s) and e-mail address of Document Author(s)/Supplier: Jagadish Ramu: Jagadish.Ramu@Sun.COM Shalini Muthukrishnan: Shalini.Muthukrishnan@Sun.COM 1.3. Date of This Document: 14-May-10 1.4. Revision History
| Date |
Change |
Revision |
Changes from previous version |
| 15-June-10 |
Changes to Application Scoped Resources after further analysis |
6 |
changes |
| 04-June-10 |
Added recommendations to Statement Leak detection and reclaim section based on comments from Siva |
5 |
changes |
| 04-June-10 |
Updating based on comments and further discussions with reviewer (Siva) |
4 |
changes |
| 25-May-10 |
Including a flag for deploy command |
3 |
changes |
| 20-May-10 |
Review ready |
2 |
changes |
| 14-May-10 |
Draft being written |
1 |
|
2. Project Summary 2.1. Project Description: This document describes the functionality changes and enhancements to Connectors, Connection Pooling, JDBC-RA 2.2. Risks and Assumptions:
- Risks: None.
- Assumptions: None.
3. Problem Summary 3.1. Problem Area: Following enhancements need to be introduced in GlassFish 3.1 to overcome or to provide :
- Absence of statement leak detection and reclaim support for JDBC applications
- Clustering support for all types of resources
- Application scoped resources to enable single click deployment of archive with resource definitions
- Reconfiguration support for datasource-definition
- Monitoring support to display :
- Connections usage in a pool grouped by different applications
- Frequently executed SQL queries by applications
- Statement cache hit/miss statistics
- Statement leaks
- Ease of use and configurability features
- Transparent reconfiguration of jdbc-connection-pool
3.2. Justification: Enhancements to existing Connectors, Pooling, JDBC-RA modules is very useful as the functionality offered by these modules are used widely among the user-base and based on the competitive appservers, these functionality improvements and changes would not only bring in performance improvements but also feature parity. The proposed features will enhance the user experience. 4. Technical Description: 4.1. Details: The Connectors, Pooling, JDBC-RA modules will have the following enhancements and features in this release 4.1.1 Statement leak detection and Reclaim Statement leak detection is a feature to detect any statements that have not been closed by the applications for a specified time period. Applications might run out of cursors if the statement objects are not closed and hence detecting them as leaks can help developers and administrators to make sure that the statement objects are indeed closed after use. The stack trace of the caller that creates the statement will be logged when a statement leak is detected. Statement leak timeout can be enabled by setting a connection pool configuration attribute statement-leak-timeout-in-seconds. Default value of this attribute is zero, indicating that the statement leak detection is turned off. Leak detection is enabled when set to a positive non-zero value. After this timeout, the statement object is considered to be leaked. Statement leak reclaim can be enabled by setting a connection pool configuration attribute statement-leak-reclaim. By default, this attribute is set to false and the statement leak reclaim is disabled. For statement reclaim to work, statement leak timeout need to be enabled. Once a statement leak is detected, leaked statement will be reclaimed. During a statement reclaim, the leaked statement(s) is closed. Connection leak timeout should be greater than the Statement leak timeout. Statement Timeout should be lesser than the Statement leak timeout. Statement leak detection is done for all new connections got in an application for an active pool. Similarly, the monitoring statistics are collected for these new connections from which statements are created. 4.1.2 Clustering support for all types of resources Clustering support for all types of resources will be provided for feature parity with V2. --target option will be supported to the following commands from V2.
- add-resources
- create-admin-object
- delete-admin-object
- create-connector-resource
- delete-connector-resource
- create-javamail-resource
- delete-javamail-resource
- create-jdbc-resource
- delete-jdbc-resource
- create-custom-resource
- delete-custom-resource
- create-jndi-resource
- delete-jndi-resource
- list-admin-objects
- list-connector-resources
- list-javamail-resources
- list-jdbc-resources
- list-custom-resources
- list-jndi-resources
4.1.3 Application scoped resources
- A feature using which applications can be deployed with resource definitions specified within the archive.
- Helps to achieve single-click deployment ability for complex archives with various type of resource requirements
- By being able to specify and hence process the resource definitions that are defined within the archive, this feature will avoid the need to redeploy the application archive that has embedded resource-adapters used by other modules within the archive.
Scope of resources
- The resources are scoped to the applications that define them ie., they are available only to the applications that defines them.
- With the introduction of scope for the resource, application is assured that a scoped resource is not used by other applications and be free from unexpected resource starvation or delay in acquiring connections.
- These scoped resources cannot be referred or looked up by other applications.
- If the resource definition is provided within an archive (ie., glassfish-resources.xml within an .ear or other archives), they are assumed to be scoped resources
- Application Scope :
- glassfish-resources.xml bundled at top level of the archive (META-INF/glassfish-resources.xml or WEB-INF/glassfish-resources.xml for .war) are exported with "application" scope ie., they can be obtained by doing the lookup with prefix "java:app". These resources are available only to the application (and its modules) in which they are defined.
- Module Scope :
- glassfish-resources.xml(s) bundled at sub-archive (sub-module) level of the archive are exported with "module" scope ie., they can be obtained by doing the lookup with prefix "java:module". These resources are available only to the module in which they are defined.
- jndi-name for application-scoped-resources or module-scoped-resources are specified using the following format :
java:app/jdbc/myDataSource or java:module/jdbc/myModuleLevelDataSource. This is in accordance with the new naming scopes introduced in Java EE 6 Specification. Refer Resources, Naming and Injection, sub-section JNDI Naming Context of Java EE 6 Specification for more details. If the prefix "java:app/" or "java:module/" is not specified in the resource's name, they will be prefixed appropriately and persisted in domain.xml
A JDBC resource and connection pool persisted as application-scoped-resource with "java:app/" prefix and module scoped resources are persisted within the module with "java:module/" prefix.
<application name="myapplication.ear">
<resources>
<jdbc-connection-pool max-pool-size="50" datasource-classname="org.apache.derby.jdbc.ClientDataSource" res-type="javax.sql.DataSource" name="java:app/jdbc/app-scoped-pool" pool-resize-quantity="20">
<property name="user" value="APP" />
<property name="PortNumber" value="1527" />
<property name="password" value="APP" />
<property name="ServerName" value="localhost" />
<property name="databaseName" value="testdb" />
</jdbc-connection-pool>
<jdbc-resource pool-name="java:app/jdbc/app-scoped-pool" jndi-name="java:app/jdbc/app-scoped-resource" />
</resources>
<module name="mywar.war">
<resources>
<jdbc-connection-pool max-pool-size="50" datasource-classname="org.apache.derby.jdbc.ClientDataSource" res-type="javax.sql.DataSource" name="java:module/jdbc/module-scoped-pool" pool-resize-quantity="20">
<property name="user" value="APP" />
<property name="PortNumber" value="1527" />
<property name="password" value="APP" />
<property name="ServerName" value="localhost" />
<property name="databaseName" value="testdb" />
</jdbc-connection-pool>
<jdbc-resource pool-name="java:module/jdbc/module-scoped-pool" jndi-name="java:module/jdbc/module-scoped-resource" />
</resources>
</module>
</application>
- applications will refer these resources with "java:app/" prefix or "java:module/" prefix in the deployment descriptor appropriately.
A sample resource-ref in glassfish-ejb-jar.xml
<resource-ref>
<res-ref-name>jdbc/app-scoped-resource</res-ref-name>
<jndi-name>java:app/jdbc/app-scoped-resource</jndi-name>
</resource-ref>
- When an application tries to look up a scoped resource that does not belong to the application (defined in another application) or module (defined in another module), naming exception will be thrown.
glassfish-resources.xml
- Resource definitions are specified via glassfish-resources.xml which should be a valid XML file that conforms to the glassfish-resources.dtd
- When used with glassfish-resources.xml, it provides EOU functionality such that resources are created/destroyed during application deploy/undeploy.
- All resources created using a glassfish-resources.xml within an application archive will be scoped.
- glassfish-resources.xml should be placed in META-INF directory of the archive (exception being .war where it should be placed within WEB-INF directory)
- glassfish-resources.xml can be defined in each sub-module (sub-archive) of an enteprise application (.ear).
- Scoping the resources also help to eliminate most of the conflicts of glassfish-resources.xml based applications against other applications or resources that already exist in the server.
- Existing add-resources command uses glassfish-resources.xml. Resources created using add-resources are global ie., they are not specific to any application.
- application/module-scoped-resources can be reconfigured using admin CLI, GUI. Refer Admin/Config Impact section for more details.
Duplicates & Conflicts
- Duplicate :
- If there is a resource definition with same resource-name, resource-type, properties and attributes, it is assumed to be a duplicate.
- Conflict :
- A conflict occurs when two resource-definitions with different properties are made for the same resource-name and resource-type.
- Duplicates & Conflicts can occur at "app" level or "module" level of resource-definitions.
- Duplicates will be logged as WARNING messages and deployment will continue.
- Conflict will result in deployment failure. Administrator will have to resolve the conflicts.
Deploy, re-deploy, undeploy
- When an application is undeployed, by default its (scoped) resources will be deleted.
- During redeployment of the application, resources will be destroyed and created based on the new resource definition in the archive.
- In order to preserve old resource definitions during redeploy (deploy --force=true), a new property preserveAppScopedResources can be used.
- preserveAppScopedResources property when set to true will keep existing resources and skip processing glassfish-resources.xml(s) in the archive.
Restriction on resource types in various application types
- Restriction on following artifacts will be applicable as they will affect the resource-adapter which can be used by other applications or global resources
- resource-adapter-config
- resource-adapter-config can be specified in a glassfish-resources.xml of corresponding connector module only (standalone RAR). In case of EAR, resource-adapter-config for the embedded RAR can be specified in the bundled glassfish-resources.xml RAR. It is not allowed to have resource-adapter-config for a RAR in an EAR where the RAR is not part of the EAR.
- connector-work-security-map
- Same restrictions as that of resource-adapter-config applies for connector-work-security-map.
- Cross references :
- an application level jdbc-connection-pool cannot be referred by module level jdbc-resource. This is not supported in this release (3.1)
- Above restriction applies to connector-connection-pool also.
- Global resources :
- java:global is not supported in this release (3.1)
- Cross definitions :
- defining "java:app" scoped resources at module level (ie., in module's glassfish-resources.xml) is not supported in this release (3.1)
Monitoring support
- Monitoring information for connection-pools (jdbc, connector) of application/module scoped resources can be obtained.
asadmin get --monitor=true server.applications.web-subclassingApp.resources.* | grep -i "\-count"
server.applications.web-subclassingApp.resources.java:app.embedded-ra-pool.averageconnwaittime-count = 19
server.applications.web-subclassingApp.resources.java:app.embedded-ra-pool.numconnacquired-count = 14
server.applications.web-subclassingApp.resources.java:app.embedded-ra-pool.numconncreated-count = 8
server.applications.web-subclassingApp.resources.java:app.embedded-ra-pool.numconndestroyed-count = 0
server.applications.web-subclassingApp.resources.java:app.embedded-ra-pool.numconnfailedvalidation-count = 0
server.applications.web-subclassingApp.resources.java:app.embedded-ra-pool.numconnnotsuccessfullymatched-count = 0
server.applications.web-subclassingApp.resources.java:app.embedded-ra-pool.numconnreleased-count = 14
server.applications.web-subclassingApp.resources.java:app.embedded-ra-pool.numconnsuccessfullymatched-count = 0
server.applications.web-subclassingApp.resources.java:app.embedded-ra-pool.numconntimedout-count = 0
server.applications.web-subclassingApp.resources.java:app.embedded-ra-pool.numpotentialconnleak-count = 0
server.applications.web-subclassingApp.resources.java:app.embedded-ra-pool.waitqueuelength-count = 0
4.1.4 Reconfiguration and monitoring support for DataSource-Definitions Java EE 6 defines @DataSourceDefinition annotation (and its equivalent in deployment-descriptor(s)) which applications can define and export data-sources across components/modules/applications.
With the current implementation, data-sources cannot be re-configured which will make it difficult or mandate application redeployment whenever the configuration of the data-source need to be changed. Also, often it is necessary to tune the connection-pool configuration according to the usage metrics. Support for re-configuration will help to avoid re-deployment of application. By providing monitoring statistics for these datasource-definitions, they can be tuned according to the usage metrics.
This feature will help to register the datasource-definition in domain.xml such that it can be re-configured. The datasource-definition configuration will be registered within the < application > element in domain.xml
<application>
<module>
</module>
<resources>
<datasource-definition>
</datasource-definition>
</resources>
</application>
Unique id
- Since all resources defined by various components, modules in the application are registered globally within < application > element as < application-scoped-resources >, it is necessary to generate unique id for the resources as multiple resources can be of same name with same scope within different modules of the application or different components of the module.
- Every deployed datasource-definition resource will have unique id generated based on the following characteristics
- global resources (eg: java:global/myResource) will have unique id as resource-name (eg: "myResource")
- app scoped (eg: java:app/myResource) in the application named myApp will have unique id as <APPNAME-RESOURCENAME> (eg: "myApp-myResource")
- module scoped (eg: java:module/myResource) in a module named myModule will have unique id as <MODULENAME-RESOURCENAME> (eg : "myModule-myResource")
- component scoped (eg: java:comp/myResource) in a module named myModule and component named myComponent will have unique id as <MODULENAME-COMPONENTNAME-RESOURCENAME> (eg : "myModule-myComponent-myResource")
Accessing or updating the configuration.
- dotted-names get command can be used to get the configuration.
- dotted-names set command can be used to re-configure the data-source.
- Dotted-names-get will look like :
server.applications.<APP_NAME>.application-scoped-resources.datasource-definition.<DATASOURCE_DEFINITION_UID>.*
eg: for a module scoped resource where application-name is 'my-app', module-name is 'my-module' and resource-name is 'my-resource' :
server.applications.<my-app>.application-scoped-resources.datasource-definition.<my-module-my-resource>.*
Also, with the help of transparent-jdbc-connection-pool-redeployment capability, changes to database specific configuration can also be handled transparent to application.
Refer 'Deploy, re-deploy, undeploy' section in Application Scoped Resources which will be applicable for data-source-definition. 4.1.5 Monitoring support for various Connection Pool and JDBC artifacts 4.1.5.1 Connections usage in a pool by applications A monitoring feature to get the number of connections in use by an application for the specified connection pool. The existing numconnused monitoring statistic gets the total number of connections used by all applications in a connection pool. This feature groups these connections used by applications. Similarly, the monitoring statistics numconnacquired and numconnreleased are grouped by applications usage. When monitoring is turned on and applications are using connection from the pool, monitoring statistics could be got using asadmin get --monitor=true command as
server.resources.testPool.application1.numconnused-current = 2
Number of connections acquired from the pool grouped by applications can be got using
server.resources.testPool.application1.numconnacquired-count = 15
server.resources.testPool.application2.numconnacquired-count = 5
Number of connections released to the pool by different applications can be got using
server.resources.testPool.application1.numconnreleased-count = 15
server.resources.testPool.application2.numconnreleased-count = 5
Above statistics will be collected when JDBC/Connector Connection Pool Monitoring is turned on. The AMX ObjectName that is used to retrieve these attribute values is "amx:pp=/mon/server-mon[server],type=jdbc-connection-pool-app-mon,name=resources/testPool/application1" for a jdbc connection pool used by application1. Similar ObjectName can be used for application2. For connector connection pools, the AMX ObjectName is "amx:pp=/mon/server-mon[server],type=connector-connection-pool-app-mon,name=resources/testCCPool/application1". testCCPool is the connector connection pool for which monitoring grouped by applications is being observed. The monitoring probes that are exposed by this feature are
- glassfish:jdbc-pool:applications:decrementConnectionUsedEvent
- glassfish:jdbc-pool:applications:connectionUsedEvent
- glassfish:jdbc-pool:applications:connectionAcquiredEvent
- glassfish:jdbc-pool:applications:connectionReleasedEvent
for jdbc connection pools and
- glassfish:connector-pool:applications:decrementConnectionUsedEvent
- glassfish:connector-pool:applications:connectionUsedEvent
- glassfish:connector-pool:applications:connectionAcquiredEvent
- glassfish:connector-pool:applications:connectionReleasedEvent
for connector connection pools.
4.1.5.2 SQL Tracing to display frequently used queries SQL query monitoring is a new feature to display the 'n' most frequently used queries by the applications in a specific time window. When SQL tracing is turned on by setting the attribute sql-trace-listeners, new connection pool configuration properties number-of-top-queries-to-report and time-to-keep-queries-in-minutes can be configured to set the value of 'n' to display the top 'n' most frequently used queries and the time to retain queries in a cache before they are purged respectively. The property time-to-keep-queries-in-minutes will represent the time window for which the queries will be kept in the cache ie., considered for calculating frequently used queries. The default value of number-of-top-queries-to-report is ten and time-to-keep-queries-in-minutes is five minutes. When monitoring is turned on and sql-trace-listeners attribute is set, administrators and developers can use the monitoring information as shown below to determine the most frequently executed SQL queries. Monitoring statistics are collected only for standard JDBC calls.
server.resources.testPool.frequsedsqlqueries-current =
query1
query2
query3
...
number-of-top-queries-to-report and time-to-keep-queries-in-minutes properties can be set to a positive non-zero value as follows :
asadmin> set server.resources.jdbc-connection-pool.<POOL_NAME>.property.number-of-top-queries-to-report=15
asadmin> set server.resources.jdbc-connection-pool.<POOL_NAME>.property.time-to-keep-queries-in-minutes=10
The AMX ObjectName that is used to retrieve this attribute value is "amx:pp=/mon/server-mon[server],type=jdbcra-mon,name=resources/testPool". The monitoring probe that is exposed by this feature is "glassfish:jdbcra:sqltracing:cacheSqlQueryEvent". 4.1.5.3 Statement Cache hit/miss Monitoring A new monitoring probe to display the statement cache hit and miss monitoring statistics. A statement cache hit indicates the number of times a Statement/PreparedStatement/CallableStatement was taken from the cache whereas statement cache miss is number of times the statement was created newly as it was not found in the cache. Statements executed repeatedly by applications can use this monitoring information to tune the statement-cache-size attribute to improve performance. Statement cache monitoring indicates the total number of statement hits and misses in a connection pool. Above statistics will be collected when JDBC Connection Pool Monitoring is turned on and statement-caching (statement-cache-size attribute of jdbc-connection-pool) is enabled.
Typical statement cache hit and miss monitoring statistics will look like
server.resources.testPool.numstatementcachehit-count = 3
server.resources.testPool.numstatementcachemiss-count = 1
The AMX ObjectName that is used to retrieve these attribute values is "amx:pp=/mon/server-mon[server],type=jdbcra-mon,name=resources/testPool". The monitoring probes that are exposed by this feature are "glassfish:jdbcra:statementcache:statementCacheHitEvent" and "glassfish:jdbcra:statementcache:statementCacheMissEvent". 4.1.5.4 Statement leak monitoring Statement leak monitoring will leverage the new feature Statement Leak Detection to get the total number of statement leaks in the application server at the sample time. Statement leaks count is calculated across all applications for the specified pool. When JDBC Connection Pool Monitoring is turned on and statement-leak-timeout-in-seconds is set to a positive non-zero value, the statement leak monitoring information will be collected. The statistic will be of the form :
server.resources.testPool.numpotentialstatementleak-count = 6
Above statistic will be collected when JDBC Connection Pool Monitoring is turned on and statement leak detection (statement-leak-timeout-in-seconds attribute of jdbc-connection-pool) is enabled. The AMX ObjectName that is used to retrieve these attribute values is "amx:pp=/mon/server-mon[server],type=jdbcra-mon,name=resources/testPool". The monitoring probe that is exposed by this feature is "glassfish:jdbcra:statementleak:potentialStatementLeakEvent". 4.1.6 New Custom Validation Templates Custom Validation templates will be introduced for databases MSSQL, DB2 and Sybase. The validation mechanisms will implement the interface org.glassfish.api.jdbc.validation.ConnectionValidation. 4.1.7 Introspect JDBC Drivers 4.1.7.1 Introspect JDBC Drivers On Request (GUI) This is an extension to the feature "Introspection of JDBC Drivers" introduced in V3 for GUI. By default, Admin console gets the implementation classnames based on the database vendor from a file called dbvendor.properties. A check box for introspection of data-source/driver implementation class-names will enable introspection. If "Introspect" check box is selected, based on the database vendor and resource type chosen, implementation class-names are displayed. Administrators can choose appropriate class-name from the introspected list to create the connection pool. This feature works on the assumption that the JDBC driver is made available to the application server. 4.1.7.2 Introspection of JDBC drivers in CLI Admin CLI prompts for Datasource or Driver class name whenever a create-jdbc-connection-pool command is issued without the respective attributes. In such cases, this feature introspects the implementation class-names and displays to the user so that user can choose the implementation class-name. This feature works on the assumption that the JDBC driver is made available to the application server. An ease-of-use feature, its of great help to the users in order to choose implementation class names from the list without the need for a lookup on the driver documentation. The list of implementation class names would be derived based on the database vendor and the resource type provided by the user. 4.1.8 OSGi RFC support from JDBC module Support for OSGi RFC for JDBC (OSGi RFC 122) can be provided in GlassFish. 4.1.9 Transparent jdbc-connection-pool re-configuration
- A feature using which redeployment of jdbc-connection-pool due to attribute or property change can be handled transparent to the applications that use the pool.
- Whenever a set of properties / attributes of jdbc-connection-pool are changed, the connection-pool is destroyed and re-created based on the new values. Any application that is using the connection-pool need to be re-deployed or application server need to be re-started due to pool re-configuration.
- Using this feature, existing applications can roll-over to new connection pool transparently.
- It is also possible that there can be in-flight transactions that is using the connections when the pool is re-configured.
- This feature will block the pool for any new connection requests, however will allow requests that have already acquired atleast one connection from the pool and is part of a transaction. Thus, in-flight transactions' connection requests will be honoured and the transaction can complete.
- A new property named 'dynamic-reconfiguration-wait-timeout-in-seconds' can be introduced that will help to allow in-flight requests to complete.
asadmin> set server.resources.jdbc-connection-pool.<POOL_NAME>.property.dynamic-reconfiguration-wait-timeout-in-seconds=30
- All new requests will wait for the pool reconfiguration to complete and connections will be acquired using re-configured pool configuration.
- All in-use connections, in-flight transactions that span even after 'wait-timeout' is elapsed will have to be re-tried.
4.2. Bug/RFE Number(s): TBD 4.3. In Scope:
- Clustering support will be provided based on v2 functionalities.
- Connections Usage by applications, SQL Tracing to display frequently used queries, Statement cache hit/miss statistics depend on whether monitoring is turned on or off.
- Statement leak monitoring will work when Statement leak detection and monitoring are turned on.
- Statement cache hit/miss monitoring will work when Statement Caching is enabled and monitoring is turned on.
- SQL Trace monitoring will work only when SQL Trace listeners are set and monitoring is turned on.
- Introspection of JDBC Drivers in GUI/CLI will work based on the existing API introduced in v3 for querying the JDBC driver to get implementation class names.
4.4. Out of Scope:
- Statement cache monitoring, SQL Trace monitoring, Statement leak monitoring could be incrementally enhanced in future releases by grouping the statistics based on applications.
4.5. Interfaces: 4.5.1 Exported Interfaces
| *Interface* |
*Stability* |
*Former Stability (if changing)* |
Comments |
- Two new flags for list-applications command will be provided
- --subcomponents and --resources
- Refer Admin/Config Impact, CLI Section for sample output
- preserveAppScopedResources
- A new property named preserveAppScopedResources need to be supported for deploy --force=true (redeploy) command which will take effect when the archive has application-scoped-resources
- Custom implementations for connection validation for databases
- org.glassfish.api.jdbc.MSSQLConnectionValidation
- org.glassfish.api.jdbc.DB2ConnectionValidation
- org.glassfish.api.jdbc.SybaseConnectionValidation
All of the above implement org.glassfish.api.jdbc.ConnectionValidation interface. 4.5.2 Imported interfaces 4.5.3 Other interfaces (Optional) 4.6. Doc Impact:
- Administration Guide
- Developer's Guide
- Administration Reference Guide
- Admin GUI online help
- Admin CLI help
- Performance Tuning Guide
4.7. Admin/Config Impact: CLI support :
- Support for new attributes statement-leak-timeout-in-seconds and statement-leak-reclaim in create-jdbc-connection-pool command.
- --target option for the commands : create-resource-ref, delete-resource-ref, list-resource-refs.
- --target option to be added for commands listed in section 4.1.2.
- New flags --subcomponents and --resources will be introduced to the command "list-applications"
asadmin list-applications --subcomponents --resources
connector16App <ear, ejb, web>
java:app/jdbc/app-level-ds <JdbcResource>
java:app/jdbc/XAPointbase <JdbcResource>
java:app/jdbc/app-level-pool <JdbcConnectionPool>
java:app/jdbc-pointbase-pool1 <JdbcConnectionPool>
connector16-ejb.jar <EJBModule>
java:module/jdbc/ejb-level-ds <JdbcResource>
java:module/eis/testAdmin <AdminObjectResource>
java:module/jdbc/ejb-level-pool <JdbcConnectionPool>
connector16-web.war <WebModule>
java:module/jdbc/web-level-ds <JdbcResource>
java:module/jdbc/web-level-pool <JdbcConnectionPool>
- ping-connection-pool and flush-connection-pool commands will accept new flags "--appname" and "--modulename" in order to support application-scoped-resources and module-scoped-resources
- Support for interactive CLI mode to introspect and display implementation class names of JDBC drivers based on database vendor and resource type.
GUI support :
- Support for adding new attributes to the JDBC Connection Pool page : advanced tab : A text field for "Statement Leak Tracing Timeout in seconds" and a checkbox for "Statement Leak Reclaim".
- GUI changes for Clustering support for all types of resources.
- GUI support for displaying, editing application-scoped-resources. ( create/delete is not supported for application-scoped-resources)
- GUI support for displaying, editing datasource-definition resource. ( create/delete is not supported for datasource-definition)
- Support to display monitoring statistics of application-scoped-resources and datasource-definition resources.
- Monitoring statistics related support from GUI :
- Support for displaying the new monitoring statistics for connections usage by applications
- Support for displaying SQL Tracing monitoring statistics to view most frequently used sql queries
- Support for displaying the Statament cache hit/miss monitoring statistics
- Support for displaying the Statement leak monitoring statistics
- Validation class-names for the default database vendors should be displayed in the GUI whenever connection validation is turned on and custom validation is chosen as the connection validation mechanism. The getValidationClassNames(String dbVendor) API from ConnectorRuntimeAPIProvider could be used for the same.
- Support for adding a new check box to the Connection Pool creation page, by name, "Introspect". When this checkbox is selected, list of implementation class-names will be displayed in the next page based on database vendor and resource type provided by the user.
Config Impact
4.8. HA Impact: TBD 4.9. I18N/L10N Impact: None. |
