Binod P G wrote On 08/24/06 09:55,:
>
> Rebecca Parks wrote On 08/24/06 21:55,:
>
>> I've been following this discussion, and I still don't see why these
>> pool settings can't be implemented as attributes. The advantage of
>> attributes is that they're right there in the DTD and anyone can see
>> what the available settings are and what their defaults are. If the
>> attributes are optional, there is no backward compatibility issue. I
>> don't mind expanding the DTD a little bit for the sake of clarity.
>> I've always been suspicious of properties because they have in the
>> past been a way of sneaking features into the product.
>
>
> That is one main reason for introducing this new set of properties.
> In the past many times, we encountered situations where we had to
> add additional tuning capability in the pool using system properties or
> by introducting another property hidden inside the JDBC driver
> property set.
>
> Generally this happen when a special request come from a team (eg.
> seebeyond wanted a periodic validation capability) or for custimer
> (sustaining team added a system property for enabling statement
> wrapping).
>
> It is not practical to change the DTD always in these cases. Mainly
> because
> the request might reach you during a patch release. Making a DTD change
> at all these occasions may not be feasible.
>
> Most (or many) of these properties are useful features. If we have
> flexible set
> of properties, it is simpler to introduce these features, perhaps in an
> undocumented way for a particular customer initially and document it
> in the
> next major release.
For undocumented features for particular customers, and for quick bug
fixes, this makes sense. But it sounds like the settings you are
proposing are supposed to be standard features in 9.1, hardly the sort
of thing you'd want to hide.
June
>
> - Binod.
>
>>
>> June
>>
>> Binod wrote On 08/24/06 08:39,:
>>
>>>
>>>>
>>>> Alternatively, we could treat all these as properties,
>>>> distinguished only
>>>> by name, so that connection pool properties are always named
>>>> "pool.*" and
>>>> any property name that doesn't start with "pool." is considered a JDBC
>>>> driver property. Given the way these properties are used, that
>>>> doesn't
>>>> feel like the right solution to me, but admittedly it will
>>>> certainly work
>>>> and it's not "terrible".
>>>
>>>
>>>
>>>
>>> That would work. But it doesnt seem the right way of implementation
>>> to me.
>>>
>>> Even if take this approach, CLI and GUI should be able to
>>> distinguish these
>>> two sets of properties. Overall, it will be simpler to modify the
>>> DTD to allow
>>> these two sets properties.
>>>
>>> - Binod.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>