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