On Mar 26, 2006, at 11:59 AM, Roman Rokytskyy wrote:

> Sorry, pressed button too fast...
>
> >> This parameter is a bit silly then since it has nothing to do with
> >> connection pooling and setting it to true breaks the driver...
> >
> > Err... I mean 'setting it to false breaks the driver'
>
> I can confirm your findings. They also happen in
> ConnectionPoolDataSource
> and are related to the fact that we are unable to handle getting
> logical
> connection few times from the single pooled connection. Since this
> code is
> in use in many installations, it proves that the typical usage
> scenario is
>
> PooledConnection pc = pool.getPooledConnection();
> Connection c = pc.getConnection();
> ...
> c.close();
>
> which is indirectly confirmed by a phrase from the JDBC
> specification "When
> an application is finished using a connection, it closes the logical
> connection using the method Connection.close. This closes the logical
> connection but does not close the physical connection. Instead, the
> physical
> connection is returned to the pool so that it can be reused." (JDBC
> 3.0
> spec, page 70).
>
> Since there is no method to return connection to the pool, this
> means such
> code is implementation specific. In our case it is returned to the
> pool when
> logical connection is closed. Now, when you try to obtain logical
> connection
> for the second time, the physical connection is in pool. We do not
> detect
> this situation and after that all goes wrong...
>
> As to the XAConnection... it is subclass of the PooledConnection,
> therefore
> it should have same semantics as PooledConnection.
>
> So, we have quite controversial results... and the worst is that I
> have not
> seen neither confirmation of your usage scenario nor that mine usage
> scenario is the only possible.
>
> What do we want to do now?

I haven't looked closely at what the current code base does.

My opinion is that use of a ConnectionPoolDataSource or XADataSource
only makes sense in a managed environment that provides essentially
the functionality of a J2CA ConnectionManager. I think it is
extraordinarily negligent of the jdbc spec authors to avoid making
this extremely clear.

Since, IMO, it doesn't make sense to use either of these in a non-
managed environment, I don't think we should try to do so, and I
think any functionality that tries to do so should be removed.

However, I also think that we should provide a miniature managed
environment in which you can set up connection pooling and hook up
with a TM. One way to do this would be to verify that Jaybird works
with the Jencks project, which runs the geronimo j2ca components in
Spring. We could write some classes to set up a connection manager
for jaybird in code, thus removing the need for Spring. We could
also come up with an even smaller environment, but I think that will
quickly be subject to diminishing returns for the effort spent.

To reiterate and summarize:
-- Only someone who is writing a framework or container should be
using ConnectionPoolDataSource or XADataSource directly.
-- We should provide a miniature framework that exposes a DataSource
and provides connection pooling and XA when a TransactionManager is
provided.

I think that basing the second of these on the jaybird J2CA Connector
and geronimo components will produce the most full-featured result
for the least work, but there are certainly other possibilities.

thanks
david jencks

>
> Roman