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

From: arjan tijms <>
Date: Sat, 14 Feb 2015 13:31:55 +0100


On Sat, Feb 14, 2015 at 11:27 AM, Romain Manni-Bucau
<> 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

Kind regards,
Arjan Tijms

> Le 14 févr. 2015 02:06, "Bill Shannon" <> a écrit :
>> arjan tijms wrote on 02/13/15 14:53:
>> > Hi,
>> >
>> > On Fri, Feb 13, 2015 at 8:33 PM, Bill Shannon <>
>> > 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
>> >
>> >
>> > but it may be possible that e.g. JBoss just doesn't know this.
>> >
>> > See
>> >
>> >
>> > 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.