> 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.
Sure I shall contact you off-list and feed back to the list if there is
anything new.
Thanks
--Siva
Larry White wrote:
> 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.
>>>>>
>>>>> ------------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>