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.
>