admin@glassfish.java.net

Re: conn. pool related domain.dtd changes for GlassFish V2

From: Bill Shannon <bill.shannon_at_sun.com>
Date: Wed, 23 Aug 2006 16:59:18 -0700

Jagadish Prasath Ramu wrote:
>>How do all these properties appear in domain.xml? Is something populating
>>domain.xml with all *possible* properties for a JDBC driver, even though
>>the user hasn't changed the value from the default? If so, fixing that
>>would likely help a lot.
>>
> Currently
> <jdbc-connection-pool>
> <property name="MaxReconnects" value="3"/>
> <property name="ConnectTimeout" value="30"/>
> <property name="AutoReconnectForPools" value="false"/>
> <property name="ReconnectAtTxEnd" value="false"/>
> </jdbc-connection-pool>
>
> During Con.Pool configuration admin-infrastructure will request the
> connectors module for properties of datasource.
>
> connectors module will introspect the db-driver provided datasource
> class and provide the properties with their default values.
>
> Yes, at present, even if the user has not changed the default value,
> they are part of con.pool configuration.

I think we should consider whether that's the best approach.
The advantage seems to be that it provides a sort of "documentation"
of all the properties you can ever possibly set. The disadvantage is
that it creates a bigger and more confusing domain.xml.

>>Who interprets these properties? I assume that the db-vendor properties
>>are interpreted by the JDBC driver, correct? Are the sun-specific
>>properties interpreted only by the app server? If we need two groups,
>>maybe that's a better way to distinguish them - JDBC driver properties
>>vs. app server properties or connection pool properties or something like
>>that.
>>
> Properties obtained from con.pool configuration will be intercepted by
> app. server and set either as con.pool property or as datasource
> object's property appropriately.

I just talked to Binod about this and now I understand this a bit better.
As I understand it, the "sun-specific" properties are properties on the
connection pool. We could, and probably should, provide an MBean that
exposes these properties as MBean properties (probably as get/set methods)
for a connection pool. As we update the connection pool implementation,
we would add more properties to this MBean, and we would like to be able
to specify values for these properties in the domain.xml file without
changing the schema, and we would like to be able to set these properties
in the asadmin "create" command without adding new command line options
(as is done for existing connection pool properties).

I think this takes us back to one of my earlier comments. It seems
reasonable to separate these properties into two groups. One group
is properties that are set on the JDBC driver. The other group is
properties that are set on the connection pool. The latter set is
what you were calling "sun-specific".

The important distinction between the two groups of properties is not
whether they're "Sun specific" or not, it's whether they apply to the
JDBC driver or to the connection pool. So, with no compatibility
constraints, I might create <driver-properties> and <connection-pool-properties>
elements in the domain.xml. But since we do have compatibility constraints,
and unfortunately we grouped the properties that apply to the JDBC driver
under a <jdbc-connection-pool> element, it's a challenge to pick appropriate
names for these elements. One possibility is:

<jdbc-connection-pool>
   <property name="MaxReconnects" value="3"/>
   <property name="ConnectTimeout" value="30"/>
   <property name="AutoReconnectForPools" value="false"/>
   <property name="ReconnectAtTxEnd" value="false"/>
   <pool-property name="ConnectionCreationRetry" value="true"/>
   <pool-property name="ConnectionCreationRetryAttempts" value="3"/>
   <pool-property name="ConnectionCreationTimeout" value="30"/>
</jdbc-connection-pool>

or, if you really want to reuse the <property> element:

<jdbc-connection-pool>
   <property name="MaxReconnects" value="3"/>
   <property name="ConnectTimeout" value="30"/>
   <property name="AutoReconnectForPools" value="false"/>
   <property name="ReconnectAtTxEnd" value="false"/>
   <pool-properties>
     <property name="ConnectionCreationRetry" value="true"/>
     <property name="ConnectionCreationRetryAttempts" value="3"/>
     <property name="ConnectionCreationTimeout" value="30"/>
   </pool-properties>
</jdbc-connection-pool>


So, bottom line, I agree with the general approach that was proposed,
but I'm suggesting a different name than "sun-specific-property".