Hi Siva:
To answer your last question about HADB, given your current
semantic assumptions, I think the answer is no. Why don't you write to
me separately and we can discuss this point more deeply on a different
thread
if you like.
In general, I still don't really understand why you think that
essentially "fail-all-connections"
behavior is always what you want even with the new ClusteredPool. It is
a very
intrusive and and in many cases, destructive programming experience to have
every executing thread which at the moment "owns" a connection from the
pool suddenly
have it closed out from under it because another connection somehow has
failed. We had to fix a bug with HADB last month because inadvertantly
fail-all-connections attribute for the pool was set to true, with
catastrophic results.
At the very least, it seems to me that this "fail-all-connections"
behavior may
force an unexpected new discipline on all application developers -
namely to be
able to react (correctly? whatever that means) to an unpredictable
closing of
their connection beyond their control. I would like to hear more of
your thinking
about this and how developers will be able to handle it. Or if I'm
right, perhaps you
should make this 'fail-all-connections' an optional thing as it is for
the existing pools.
I think a more graceful behavior is to let existing connections that
have been taken
from the pool and are thus in use to continue to be used. And once
returned to the
pool they are then closed as part of the fail-over to another pool. I
guess you could
call this a form of quiescing behavior. It's true that in some cases
(but perhaps not all),
that the failure of one connection will correspond to the same failure
with other
connections in the pool but at least the developer's code will discover
this in a more
'normal' fashion.
regards, Larry White
Sivakumar Thyagarajan wrote:
> 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.
>>>>
>>>> ------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>