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