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

yes was mainly thinking about validation/test configs (query,
interval, when to test ie on borrow, on return etc). uwrap(Type)
sounds interesting but that's more a DataSource feature than a EE one
no?


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-02-17 8:53 GMT+01:00 arjan tijms <arjan.tijms_at_gmail.com>:
> 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 to this 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.
>>