Hi Larry
Thanks for your comments.
>> There may be more semantic issues like this and we need to scrutinize
>> this very carefully,
>> especially if this new type of pool is to be the only choice in the
>> future.
As Jagadish has mentioned, the ClusteredPool is _not_ the default and is
only available only when a connector or JDBC resource is created
pointing to more than one connection pool. We expect users to use
ClusteredPools only when they explicitly want "load-balanced" connection
pooling to multiple EIS/database(Oracle RAC) nodes.
On a related note, would it be possible/useful to engineer changes so
that the HADB infrastructure could leverage ClusteredPool going forward?
Thanks
--Siva.
Jagadish Prasath Ramu wrote:
> Hi Larry,
> Please find my responses in-line.
> On Mon, 2006-08-21 at 10:01 -0700, Larry White wrote:
>> Folks:
>>
>> I have a few comments and questions about the connection pool features,
>> particularly from the perspective of HADB's use of the jdbc-resource and
>> connection-pool.
>>
>> The high level question is: will we still be able to use the existing
>> non-clustered
>> connection pool with no issues of compatibility?
> Yes. ClusteredPool is a new feature. It does not affect normal
> connection pools. Please refer the onepager
> <http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/ConnectionPoolOnePager.html>
> for more details for the env.
> in which ClusteredPools will be of use.
>> We do not want to introduce
>> any regressions caused by this new feature.
>>
>> I am seeing some important problems in the semantics you propose for
>> the behavior of this clustered pool particularly if we tried to use it
>> with HADB.
>> For example, your one-pager has the following:
>>
>> */"The connections are load-balanced and failed-over to healthy nodes
>> only during connection request from the application. There is no
>> fail-over support for connections of in-flight transactions.
>> ClusteredPool uses the connection-validation feature of the connection
>> pool. When a connection is requested by the application,
>> clustered-pool will choose a pool from its list and validates the
>> connection. If the validation is successful, connection is returned to
>> the user. If the connection is invalid, clustered-pool will fail-over
>> to other available pools. All connections in the failed-pool will be
>> dropped."/*
>>
>> The problem here is that we already have (with HADB) a
>> well-established and tested mechanism whereby an attempt to create a
>> connection will be retried (and most often succeed) by our app server
>> code calling through the HADB JDBC driver. In this situation, it
>> would be very very bad to do what you state in the last sentence here:
>> "All connections in the failed-pool will be dropped."
> This behavior is only for ClusteredPool.
>>
>> There may be more semantic issues like this and we need to scrutinize
>> this very carefully,
>> especially if this new type of pool is to be the only choice in the
>> future.
>> regards, Larry White
>>
> Thanks,
> -Jagadish
>> Jagadish Prasath Ramu wrote:
>>> Hi,
>>> We have proposed the one pager for connection pool features
>>> <http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/ConnectionPoolOnePager.html>,
>>> which involves DTD changes. (diff attached)
>>>
>>> we have updated the "Domain Configuration Management Process" wiki
>>> page for GlassFish V2 Release
>>> <http://www.glassfishwiki.org/gfwiki/Wiki.jsp?page=GlassFishV2ApplicationServer9.1>
>>>
>>> Thanks,
>>> -Jagadish, Kshitiz
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------------------------------
>>> * DTD changes associated with clustered-pool
>>>
>>> 554a555,560
>>>
>>>> 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.
>>>>
>>>>
>>> 2825c2912
>>> < <!ELEMENT connector-connection-pool (description?, security-map*, property*)>
>>> ---
>>>
>>>> <!ELEMENT connector-connection-pool (description?, security-map*, sun-specific-property*, property*)>
>>>>
>>> 2955a3043,3055
>>>
>>>> <!-- sun-specific-property
>>>> Syntax for providing application server specific features for
>>>> connection-pool
>>>>
>>>> Used in:
>>>> connector-connection-pool, jdbc-connection-pool
>>>>
>>>> -->
>>>> <!ELEMENT sun-specific-property (description?)>
>>>>
>>>> <!ATTLIST sun-specific-property
>>>> name CDATA #REQUIRED
>>>> value CDATA #REQUIRED>
>>>>
>>>
>>> Comments : The above is list of DTD changes for introduction of sun-specific property.
>>> An optional element sun-specific-property is introduced for jdbc and connector
>>> connection-pool. It is similar to element property. It will hold name and value pair.
>>>
>>> ------------------------------------------------------------------------------------------------------
>>>