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?

Roman