users@javaee-spec.java.net

[javaee-spec users] Re: Improving data-source element with facility for vendor specific pool settings?

From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
Date: Tue, 17 Feb 2015 00:44:56 +0100

Well TomEE jas not really this issue was more for the spec. About resource
management wording was surely poor but idea is to keep resources
configurable beans and avoid to constraint them with a predefined set of
properties.
Le 17 févr. 2015 00:32, "Bill Shannon" <bill.shannon_at_oracle.com> a écrit :

> You can always use "tomee.pool.ageMax" or something like that.
>
> I didn't understand your comment about resource management.
>
> Romain Manni-Bucau wrote on 02/14/15 06:22:
>
> Ps: in tomee we use setters on pool as well so age-max wouldnt be
> supported and is opposed to the resource management we try to do
> Le 14 févr. 2015 13:31, "arjan tijms" <arjan.tijms_at_gmail.com> a écrit :
>
>> Hi,
>>
>> On Sat, Feb 14, 2015 at 11:27 AM, Romain Manni-Bucau
>> <rmannibucau_at_gmail.com> wrote:
>> > What is mandatory IMO to make it a bit portable is to standardize keys
>> for
>> > basic configs (min/max size, eviction..., and pool usage or not).
>>
>> Indeed, another step in making it a bit more portable is seeing what
>> additional pool properties can be standardized for a next version.
>> There's now a handful of them that were established years ago. I think
>> it wouldn't hurt to at least take a look at whether we can expand this
>> set.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>> >
>> > Le 14 févr. 2015 02:06, "Bill Shannon" <bill.shannon_at_oracle.com> a
>> écrit :
>> >
>> >> arjan tijms wrote on 02/13/15 14:53:
>> >> > Hi,
>> >> >
>> >> > On Fri, Feb 13, 2015 at 8:33 PM, Bill Shannon <
>> bill.shannon_at_oracle.com>
>> >> > wrote:
>> >> >> Here's how we expected this to work...
>> >> >>
>> >> >> Any property that matches a JavaBeans property on the JDBC vendor's
>> >> >> DataSource implementation would be set on an instance of that class.
>> >> >> The rest of the properties, or maybe just all of the properties,
>> >> >> would be passed to the connection pool implementation to configure
>> >> >> the connection pool. Nothing other than the connection pool
>> >> >> implementation
>> >> >> needed to know which properties were for the connection pool.
>> >> >>
>> >> >> Is there a reason that won't work?
>> >> >
>> >> > The DataSource implementation is unknown in general. Suppose that my
>> >> > custom one happens to have a property called "useStrictMin" and that
>> >> > this just happens to be a property of the pool as well. In that case
>> >> > how does the implementation know which property to set? Both?
>> >> > DataSource? Pool? None? Throw exception?
>> >>
>> >> We would recommend that the connection pool properties not be of a form
>> >> that could be confused with the JavaBeans properties on the DataSource,
>> >> e.g., "org.glassfish.useStrictMin" or "use-strict-min".
>> >>
>> >> > Additionally, I wonder, is it really clear to vendors and users alike
>> >> > that the general properties can now go to either the pool or the data
>> >> > source?
>> >>
>> >> Presumably the users understand what the properties are doing and don't
>> >> really need to understand how they're routed to the right component.
>> >>
>> >> > I know that IBM 100% gets this (see
>> >> >
>> >> >
>> http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/cdat_datres.html?cp=SSAW57_8.5.5%2F1-3-0-23-3-0-0-3
>> )
>> >> > but it may be possible that e.g. JBoss just doesn't know this.
>> >> >
>> >> > See
>> >> >
>> http://grepcode.com/file/repo1.maven.org/maven2/org.wildfly/wildfly-connector/8.2.0.Final/org/jboss/as/connector/deployers/datasource/DirectDataSourceInjectionSource.java#193
>> >> >
>> >> > From the source it's clear that JBoss compares all properties against
>> >> > the configured DataSource class, and throws away everything that's
>> not
>> >> > a property of the DataSource. It doesn't even attempt to set anything
>> >> > on their pool.
>> >>
>> >> As I understand it, GlassFish currently doesn't set anything on the
>> >> pool either. We just haven't gotten around to implementing that
>> because
>> >> there hasn't been demand for it.
>> >>
>> >> > While I know that vendor specific properties themselves are always
>> >> > non-portable, in the case of the standard and portable data-source
>> >> > element it means the element can not be used at all with some
>> vendors,
>> >> > and that the vendor specific way to define data sources must be used.
>> >> > I wonder if the EE spec can do anything to mitigate this somewhat.
>> >>
>> >> The only thing I can think of is requiring that *if* the vendor's
>> >> connection pool has configurable properties, there must be a way to
>> >> set them through properties in the DataSourceDefinition. But I think
>> >> that might be going too far since it's getting into a very
>> implementation
>> >> specific area. Plus, it would be essentially untestable.
>>
>
>