At this point I think we need to hear from some of the other vendors.
If you don't do this, why not? Would you object to the proposed requirement?
(*If* the vendor's connection pool has configurable properties, there must be
a way to set them through properties in the DataSourceDefinition.)
From the GlassFish side I can say the main reason we haven't done this
is because there's way too many things we could be doing and this just didn't
seem like one of the more important things.
One of the reasons I've been hesitant to add requirements in areas such as
this is that it might inhibit vendor innovation. It should be possible to
have an implementation with no, or very limited, pooling. It should also
be possible to have a very sophisticated connection pooling implementation
that's nothing like anything we've seen so far, and thus might have
completely unexpected configuration requirements. To allow all these
possibilities, the requirements in this area have to be relatively weak
and flexible.
Adding a "should" requirement is relatively low cost, but of little value
if no one actually implements it.
Adding a "must" requirement has to be done carefully to avoid over-constraining
vendors.
And at the end of the day, pretty much all of this is going to be
non-portable, so will it really make that much difference to applications?
Do other developers think this is one of the more important things we should do?
arjan tijms wrote on 02/14/15 04:27:
> Hi,
>
> On Sat, Feb 14, 2015 at 1:57 AM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>> 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".
>
> That would absolutely work indeed, and I was indeed thinking of
> something similar.
>
> Unfortunately, that's not how it's being adopted in practice. As per
> the example above, IBM uses connection pool properties named
> "agedTimeout", "authDataAlias", etc. which all could be properties for
> the DataSource just as well.
>
> Perhaps the spec should at least express this recommendation? Better
> would be an actual separation, but in absence of that just stating the
> recommendation would already be a huge step up.
>
>> 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.
>
> Well, I can express a demand for that ;) I'l create an issue for it
> then at the GlassFish jira.
>
>> 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.
>
> It would be untestable indeed, which as we've seen with some other
> specs not rarely means it just doesn't happen, or doesn't happen
> correctly.
>
> Here too though, just stating that the vendor *must* do this *if*
> there are configurable connection pool properties does make the
> situation better. At the very least it will be easier for people to
> address the individual vendors. I.e. it's much easier for me if I go
> to vendor X and say "The spec says you should or must do this and
> that, but you are not doing it", vs "I'd like to have this feature or
> enhancement, could you add it?".
>
> Kind regards,
> Arjan Tijms