users@javaee-spec.java.net

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

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Fri, 13 Feb 2015 16:57:53 -0800

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.