users@javaee-spec.java.net

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

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Wed, 18 Feb 2015 23:38:32 +0100

Hi,

On Wed, Feb 18, 2015 at 7:44 PM, Kevin Sutter <sutter_at_us.ibm.com> wrote:
> Sorry it took a bit for me to respond. We (WebSphere) agree that we should
> not be standardizing connection pool properties. This should stay
> vendor-specific to allow for flexibility and innovation, as Bill put it.
> Although Arjan claimed that IBM "gets it" with passing connection pool
> properties through to the data source, we don't allow all connection pool
> properties to be set this way.

Okay, maybe I was a bit too fast with the "100%" qualifier. But it's
surely a good thing that IBM realizes that the general properties can
not just configure the data source, but the pool as well.

Maybe I'm completely wrong here, but reading back some issues and mail
discussions regarding the data-source element I couldn't help but get
the impression that some vendors just weren't entirely sure how to
implement the facility and have indeed missed that general properties
can also be used to configure the pool.

I'm curious though why you don't allow all connection properties to be
set this way. Is this because of a technical reason (i.e. config too
complicated to express as key/value), or is it some political thing?

> And, we really don't want to be tied to a
> standard requiring this process.

Which of the proposed processes would that exactly be?

Would adding a small set of additional standard attributes impede the
ability to innovate? I.e. there's now a "maxIdleTime" defined as
standard attribute. Let's say there would be a "minIdleTime" added.
Would the existence of that single new attribute hinder you to be
flexible?

Kind regards,
Arjan Tijms


>
> -- Kevin
>
>>
>> arjan tijms wrote on 02/16/15 23:53:
>> > Hi,
>> >
>> > On Tue, Feb 17, 2015 at 12:31 AM, Bill Shannon
>> <bill.shannon_at_oracle.com> wrote:
>> >> If you think there's more common properties that we should add tothis
>> >> list,
>
>> >> let me know what the properties are, and which vendors already
>> >> implement
>> >> them.
>> >
>> > Sure, I'll do some research to see what's exactly out there. From the
>> > top of my head it might be validation statements. I remember working
>> > with a number of pools that had some facility to test whether the
>> > connection was still valid. E.g. by executing "select 1" (see
>> >
> http://stackoverflow.com/questions/3668506/efficient-sql-test-
>
>> query-or-validation-query-that-will-work-across-all-or-most)
>> >
>> > Btw, just thinking out loud, but another avenue could perhaps be the
>> > specification of some interceptor or wrapper on the pool that the
>> > vendor uses. This could then expose some basic pool operations to user
>> > code, and could potentially offer a "getWrapped" which gives
>> > non-portable applications access to the actual pool (just like JPA
>> > does with the EntityManager).
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> >>
>> >>
>> >> arjan tijms wrote on 02/14/15 04:31:
>> >>> 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.
>> >>
>>