| Item |
Type |
Comment |
Response |
| 4.1.1 |
Clarification |
Please clarify what happens during statement reclaim. Is Statement.close() called? This would work for CallableStatement and PreparedStatement as well. Please indicate that explicitly. Any recommendations of the usage of this feature wrt connection leak detection and reclaim (such as connection leak timeout should be far greater than statement timeout etc)? Would you explicitly close related ResultSets before closing the statement in the case of statement reclaim.? |
During a statement reclaim, the leaked statement(s) is closed. There is no need to close the ResultSets explicitly as they will be closed during a Statement.close(). Will add the recommendations "Connection leak timeout should be greater than the statement leak timeout" and "Statement timeout should be lesser than the Statement leak timeout". These can also be added to the documentation. |
|
| 4.1.2 |
Correction |
Please add resource-adapter-config, connector-security-map, connector-work-security-map to the list |
These resources do not have target as they are applicable to all instances |
|
| 4.1.2 |
Enhancement |
Can we add a "delete-resources" as an opposite command for "create-resources" as part of this release? |
This enhancement could cause issues when a pool is deleted and is referred to by a jdbc resource not created using the add-resources. A pool with the same name (in the xml file) could have been created using the CLI. But the jdbc resource could have a different name. The delete-resources command would fail in this case. |
|
| 4.1.3 |
Clarification |
can a resource-adapter-config definition for a different resource-adapter than the one it is bundled under be allowed? |
No. Since ResourceAdapterConfig will affect the resource-adapter which may be used by other applications/global resources, this is not allowed. We shall update the one-pager with more clarification |
|
| 4.1.3 |
Clarification |
Please clearly state that there is no module-level visibility(ie a resource defined in an ejb-jar of an ear is visible to the war in that ear) |
By default, all resources are defined with application-level-visibilty ie., "java:app/" which is stated in the description of application-scoped-resources |
|
| 4.1.3 |
Clarification |
Can application scoped resource be reconfigured? If yes, the last bullet point in section "glassfish-resoucres.xml" must be one level up? |
Yes, this was a typo while formatting. It applies to all of application-scoped-resources. This will be fixed in the one-pager |
|
| 4.1.3 |
Suggestion |
rename "preserve-app-scoped-resources" to "preserve-resources"? |
Since there is --cascade flag in "undeploy" for globally defined resources, we prefer keeping app-scoped-resources or application-scoped-resources term |
|
| 4.1.3 |
Clarification |
Under section "Restriction on resource types in various application types", does this mean the artifacts listed can only be specified in the glassfish-resources.xml of the RAR? Why is this so? Why can't a RAR's resource be specified in the root glassfish-resources.xml of the EAR? |
Its possible. We wanted to make the RAR self contained with all its configuration. We shall remove the restriction of not allowing the above resource types (resource-adapter-config, connector-work-security-map) in other glassfish-resources.xml than that of the resource-adapter. This will be fixed in the one-pager. |
|
| 4.1.3 |
Clarification |
Would we continue to support sun-resources_1_4.dtd? |
Yes, but deprecated which is in accordance with the plan for all sun-* descriptors. Will provide a reference to deployment one-pager |
|
| 4.1.4 |
Correction |
Two modules in different applications can have the same name. So the unique id for module scoped DataSourceDefinitions should include appname as well. |
No, even if they share the same name, they will not be visibile to other applications as the naming scope is per application. |
|
| 4.1.4 |
Clarification |
How is application redeployment handled? Would exisiting DataSourceDefinitions be retained or be replaced with new configuration in the application? |
This is similar to the behavior of application-scoped-resources as it is stored within application-scoped-resources. I shall add a note in the appropriate section. |
|
| 4.1.4 |
Clarification |
Would DataSourceDefinitions with name as "java:global/XXX" also be placed under the <application> element in domain.xml and its dotted name would also be via the app? If yes, that sound counter-intuitive. Please explicitly clarify this. |
Yes. It will not be intuitive to store the configuration at different places in domain.xml which will make it difficult for the application deployer. Also, it is necessary to determine which application is exporting the data-source that will be necessary for re-deployment/ undeploy. |
|
| 4.1.4 |
Clarification |
In the dottedname example shown, please show sample usage for a DataSourceDefinition with name say "java:module/XXX" |
OK. This will be provided in the one-pager |
|
| 4.1.5.4 |
Clarification |
Should there be a statement-reclaim-success-count and statement-reclaim-failure-count based on success/fail of statement reclaim? |
The failure of statement reclaim could happen very rarely ex: when database is inaccessible. Not sure if this monitoring statistic is really needed. |
|
| 4.1.8 |
Clarification |
Provide a link to the OSGi onepager? |
OK. This will be fixed in the one-pager |
|
| 4.1.9 |
Clarificaition |
Will in-flight connections that don't return within the configured timeout be killed? If yes, please state that explicitly. |
Yes, once the timeout elapses they will follow the usual behavior of re-configuration where all connections will be killed. Any in-flight connections/transactions will have to be re-tried. |
|
| 4.1.9 |
Clarification |
Can this be done for connector connection pools too? If no, why not? |
A POC was done for all connection-pool (any resource-adapter) before writing the one-pager and there are still some use-cases where redeployment cannot be handled transparently eg: lazy-connection-enlistment, lazy-connection-association where the connection-manager will get recreated. With JDBC-RA it is possible to introduce custom contract to handle re-deployment dynamically. |
|
| 4.1.9 |
Enhancement |
Can we ping pool before reconfigure and only on success proceed with reconfiguration (similar to GFV3JDBCOnePager#section-GFV3JDBCOnePager-4.1.11PingPoolDuringCreation)? |
ping=true attribute will ping and indicate the results. It does not prevent the reconfiguration of faulty values. This will be a nice RFE. Also, AFAIK, it is not possible to prevent the configuration from getting updated in domain.xml as backend will get the event only after the configuration is updated in domain.xml |
|
| 4.1.9 |
Clarification |
Clarify explicitly that this is available for DataSourceDefinition reconfiguration too. |
This is already stated in the datasource-definition section. "Also, with the help of transparent-jdbc-connection-pool-redeployment capability, changes to database specific configuration can also be handled transparent to application." |
|
| 4.5.1 |
Suggestion |
rename list-application-scoped-resources to list-app-scoped-resources or list-app-resources to align with other commands? |
We prefer application-scoped-resources and hence change the flag name for "deploy" command |
|
| 4.7 |
Clarification |
GUI support: why should "Introspect" explicitly be selected? Can't this be the default? |
This is not the default as of now, as we had introduced dbvendor.properties to get the default classnames for common databases. Introspect, in a few cases lists many classnames in a list. First time users might have to refer the documentation for commonly used classnames to use in his application. That is the reason why a classname is chosen as default from the pre-defined list. |
|
| 4.7 |
Clarification |
Config impact: GFV31ConnectorsJDBC_DTD_jdbc-connection-pool : use of the word "default" twice in statement-leak-timeout-in-seconds description. Do we need to say statement-leak-timeout-in-seconds must be greater than statement-timeout-in-seconds here? |
Will correct this in the one pager. Will also add the recommendations to the DTD. |
|
| 4.7 |
Enhancement |
GFV31ConnectorsJDBC_DTD_data-source-definition When we persist a datasource definition in domain.xml, why can't we persist it as a jdbc-connection-pool? That way the user gets so much more richer information during re-configuration and monitoring? |
We do not allow other naming scopes (module/comp) in jdbc-resources/pools in application-scoped-resources. We do not have @DSD's equivalent way in glassfish-resources.xml to define "java:comp" scope for resources. We will have to generate two artifacts (jdbc-resource and jdbc-connection-pool) to represent a @DSD. Since @DSD is internally making use of GlassFish's connection-pool, all of the monitoring statistics will still be available. |
|
| 4.7 |
Clarification |
DTD changes for glassfish-resources_1_4.dtd: can we remove this because these changes are available in the next bullet item? |
No. The plan is to have an glassfish-* equivalent version of existing sun-* equivalent and a new version of glassfish-* for new additions to DTD. UPDATE : With the recent discussions in dev@GF , it is decided to provide only one version of glassfish-* equivalent version for both the cases ie., renaming and adding new attributes/elements. |
|
