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:20:07 +0100

Hi,

On Wed, Feb 18, 2015 at 7:49 PM, Romain Manni-Bucau
<rmannibucau_at_gmail.com> wrote:
> well was not the proposal at all. The point is to ensure datasource
> are usable in something else than PoC.
>
> For it you need 2 things mainly:
> - basic size config
> - eviction/validation
>
> Last is missing and could be standardize a minimum (even if it is
> without an evition thread and only on return and on borrow).

Indeed, I agree with all of the above. The goal is to make the
data-source element something that is usable for other things than
just PoC, examples or things with extremely moderate requirements.

To that end there were a number of things proposed, not necessarily
all mutually exclusive:

* (XML) syntax to separate properties that go to the pool from those
that go to the data source
* Amending the spec by clarifying that vendors *should* use the
general properties to configure the pool (if applicable for the pool
in question)
* Same as the above, but saying *must*
* Have some sort of wrapper or interceptor via which users as a last
resort can programmatically configure a pool (user vendor specific
APIs)
* Standardize a small set of additional pool properties, e.g.
eviction/validation

Kind regards,
Arjan Tijms

>
> wdyt?
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-02-18 19:44 GMT+01:00 Kevin Sutter <sutter_at_us.ibm.com>:
>> Bill Shannon <bill.shannon_at_oracle.com> wrote on 02/17/2015 04:10:36 PM:
>>
>>> From: Bill Shannon <bill.shannon_at_oracle.com>
>>> To: users_at_javaee-spec.java.net
>>> Date: 02/17/2015 04:11 PM
>>> Subject: [javaee-spec users] Re: Improving data-source element with
>>> facility for vendor specific pool settings?
>>>
>>> If you come up with connection pool features that you think should be
>>> standardized, the best approach is to contact the JDBC Spec Lead -
>>> Lance Anderson <lance.andersen_at_oracle.com>
>>>
>>> So far, there hasn't been much vendor support for standardizing additional
>>> connection pool attributes.
>>
>> 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. And, we really don't want to be tied to a
>> standard requiring this process.
>>
>> -- 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.
>>> >>
>>>