Changes to Connection Pool Configuration to Support ClusterdPools Original Request: 18 Aug 2006. <pre> > attributes : > pool-name > the pool-id associated with the resource. > In case of clustered-pool, it can be a comma separated > list of available connection pools. > 643a650,656 > attributes > > pool-name > the pool-id associated with the resource. > In case of clustered-pool, it can be a comma separated > list of available connection pools. > Comments : This is only a description change. Now pool-name can take comma-separated connection-pool ids. The DTD has no impact as such. ------------------------------------------------------------------------------------------------------
- DTD change associated with introduction of sun-specific-property
2569a2583,2621 > sun-specific-property > To enable application server specific connection pool features. > (See <sun-specific-property>) > > The following are the names and corresponding description for these > properties > > LeakTracing > To aid user in detecting potential connection leaks by > application. > > ConnectionLeakTimeout > The period after which connection is considered to > be leaked. > > ConnectionCreationRetry > To retry connection creation for specific number of > times, at specified intervals > > ConnectionCreationRetryAttempts > The number of attempt to create a new connection > when requested by application > > ConnectionCreationRetryInterval > The time interval between successive retry to create > a connection > > ValidateAtmostPeriod > Validates atmost once in the specified time-interval > > StatementTimeout > Sets the timeout property of a connection to enable > termination of abnormally long running queries. > > PollInterval > The time interval between successive polling of failed node. > Applicable only for clustered pool. > 2725c2777 < <!ELEMENT jdbc-connection-pool (description?, property*)> — > <!ELEMENT jdbc-connection-pool (description?, sun-specific-property* property*)> 2762a2815,2849 > sun-specific-property > To enable application server specific connection pool features. > (See <sun-specific-property>) > > The following are the names and corresponding description for these > properties > > LeakTracing > To aid user in detecting potential connection leaks by > application. > > ConnectionLeakTimeout > The period after which connection is considered to > be leaked. > > ConnectionCreationRetry > To retry connection creation for specific number of > times, at specified intervals > > ConnectionCreationRetryAttempts > The number of attempt to create a new connection > when requested by application > > ConnectionCreationRetryInterval > The time interval between successive retry to create > a connection > > ValidateAtmostPeriod > Validates atmost once in the specified time-interval > > PollInterval > The time interval between successive polling of failed node. > Applicable only for clustered pool. > Response from km105526@dev.java.net on 18 Aug 2006.
- the jdbc-resource and connector-resource are the elements that
have pool-name as an attribute and that contains the value of the name of the jdbc/connector-connection-pool defined in the same config. So, in effect, you are suggesting changing the description of the "pool-name" attribute from this, to a list names that are comma separated. Is that right?
- if yes, then what are the implications of the same on the creation
of jdbc-resource itself? For example, will the following kind of config now be seen in domain.xml:
resources .. jdbc-resource jndi-name="jdbc/clustered-pool" pool-name="jcp1,jcp2" .../ jdbc-connection-pool name="jcp1" .../ jdbc-connection-pool name="jcp2" .../ /resources
- if yes, then this is not a change in the description alone. It gives me
an impression that you are using existing infrastructure to expand the relationship between a resource and connection-pool. Currently, the relationship is one->one and you are extending it to be one->many. Is that right, or am I missing something?
- this is most likely going to complicate the behavior of --cascade option on
delete-jdbc/connector-connection-pool commands. Can you give a little more thought to it? This is of course, if above is correct.
- Secondly, why do you need a <sun-specific-property> which is just
same as <property> element? Why can't we reuse <property>? After all, <property> was designed to take care of vendor specific configuration options.
Lloyd's Response From an API (eg AMX) perspective, I strongly dislike comma-separated lists of values. It forces the user to do an "all or none" whack of the value eg use a String[]. It forces the AMX code to parse the value to provide a decent API, which further couples the code: String[] getPoolNames(); <= attribute must be parsed. Also, we typically are lax about saying whether the following are all equivalent. Are these the same, or not? {p1,p2,p3}
Unknown macro: {p1, p2, [3}
{p1,p2, p3} {p1,p2, p3} What about {p1,,p2,p3} </pre>
{p1,p2,p3} {p1,p2,p3} Whatabout {p1,,p2,p3} </pre> ----color:purple;OldURLread-only:http://wiki.glassfish.java.net/Wiki.jsp?page=ClusteredPoolDTD%% |