use of PooledConnection and ConnectionPoolDataSource

[Douglas Surber]

Mark,

We don't want to over specify beginRequest/endRequest. They will have 
default implementations that do nothing, so the spec must allow that. 
In particular that means we can't specify error detection. It is 
important that they have default implementations so it is guaranteed 
that there is no pain for a framework that calls these methods. We 
want all frameworks that do not use getConnection/close to add calls 
to beginRequest/endRequest as soon as possible. By having default 
implementations the frameworks don't have to wait for vendors to 
implement these methods.

One way to think about it is that PooledConnection.getConnection 
calls beginRequest on the underlying physical Connection and logical 
Connection.close calls endRequest on the underlying physical 
Connection. We cannot change the spec to require getConnection/close; 
that has been rejected by the vendors. But it was agreed that we can 
require frameworks to call either getConnection/close OR 
beginRequest/endRequest.

I know what Oracle Database JDBC drivers do with this information. I 
don't know what other vendors' drivers do/will do. We do not want to 
over specify. The way I think about it is that a driver may replace 
the database connection (small 'c') between requests. There's no 
requirement that it do so, but it is permitted. This is where the 
notion of local state comes from. Local state is any state associated 
with a Connection that is local to that Connection either in the 
client or the database and that is not transparently reproducible. 
Committed database data is clearly not local. An open transaction 
would be local.

I have no problem with changing the spec in line with the goals I 
stated above, especially the notion that 
PooledConnection.getConnection calls beginRequest and logical 
Connection.close calls endRequest.

This is a hack. The original connection pooling spec was unclear and 
vendors interpreted it in different ways. We proposed clarifying the 
spec to require getConnection/close which we think was the original 
intent, but that was rejected. beginRequest/endRequest is an 
alternative to getConnection/close which is acceptable to the 
vendors. The ultimate goal is for all frameworks to notify the 
underlying driver when a Connection is in use and when it is idle.

Douglas

At 01:28 AM 8/12/2015, Mark Rotteveel wrote:
>On Tue, 11 Aug 2015 09:17:29 -0700, Douglas Surber
><douglas.surber at oracle.com> wrote:
> > The request boundary methods notify the core driver of when a
> > connection is in use and when it is in a pool. Ideally
> > PooledConnection.getConnection and Connection.close should have
> > provided that information but that's not how it worked out. Some
> > pools don't use PooledConnection at all. Some use 
> PooledConnection
> > but actually pool the Connection handle returned by
> > PooledConnection.getConnection and never call close. In either 
> case
> > the core driver doesn't know when a physical Connection is in use 
> by
> > an app and when it is sitting idle in the pool. Request 
> boundaries
> > are a substitute for PooledConnection.getConnection and
> > Connection.close for those pools that don't use them.
>
>I know that connection pools are a weird and magic place (in part 
>caused
>by lack of clarity and detail in present (or past) specifications. I 
>think
>this should be addressed primarily by improving the specification of
>existing interfaces, methods and expected behaviors.
>
>I can also see why a beginRequest and endRequest might be useful for
>connection pools that don't use ConnectionPoolDataSource (or use it
>incorrectly), but the current proposal lacks in detail, clarity and
>specification expected or discouraged behavior. This will only serve 
>the
>make JDBC connection pools a weirder and more magical place, because 
>each
>and every driver will do what they please (or do nothing at all), 
>leading
>to more and not less inconsistent behavior between drivers and 
>connection
>pools.
>
>I think at minimum the driver should specify the expected outcome 
>and
>failure conditions of a call to these methods, in addition to 
>specifying
>prohibited/discouraged behavior.
>
> > How a driver makes use of this information is totally up to the
> > driver. There is no intent to specify that a driver do anything 
> in
> > particular. What the spec does require is that pools and other
> > frameworks call these methods at specific points so that the 
> driver
> > can do whatever it wants.
>
>JDBC users (if they are connection pools, or users of connections
>themselves), need to be able to have a common understanding and 
>mental
>model of JDBC connections, irrespective of the underlying 
>implementation. I
>think leaving everything up to the driver is a bad idea, because it 
>doesn't
>allow users to build that model, and will cause pain.
>
> > The spec says that there is no dependence on local state across
> > requests.
>
>And exactly what does that mean?
>
> > As a result the core driver could close the physical
> > connection on the first endRequest and open a new one on the 
> first
> > beginRequest or other action. That's just an example of what a 
> driver
> > might do. What it actually does is intentionally unspecified.
>
>I propose that at the beginRequest should specify something like 
>"After a
>call to beginRequest, the Connection must be in the same state and
>configuration as if it was just created." (which based on my reading 
>of the
>JDBC spec includes resetting the autoCommit state to true, and 
>closing any
>open resources, and maybe resetting things like transaction 
>isolation,
>etc), and endRequest something like "After a call to endRequest the
>connection will release all resources (Statements, ResultSets, etc), 
>and
>rollback any active transactions" (ie: do everything short of 
>actually
>closing the connection). For error conditions, I'd think that 
>participating
>in a distributed transaction should lead to an error for calling 
>either
>method, as would calling on a really closed connection, and it 
>should
>propagate errors that are the result of the actions to bring the 
>connection
>in the state specified above.
>
>Mark