Roman,

This parameter is a bit silly then since it has nothing to do with
connection pooling and setting it to true breaks the driver...

Anyway even when pooling is turned on, digging a bit the driver
capabilities reveals quite some flaws related to those Connection
objects returned by XAConnection.

This test fails:

for (int i=0; i<10 ;i++) {
XAConnection xac = fbDataSource.getXAConnection();
Connection c = xac.getConnection(); // will fail on 2nd loop iteration
c.close();
Connection c2 = xac.getConnection();
c2.close();
xac.close();
}

with this exception:

java.lang.IllegalStateException: Cannot execute desired operation
because pooled connection has invalid state.
at
org.firebirdsql.pool.PingablePooledConnection.checkValidity(PingablePooledConnection.java:174)
at
org.firebirdsql.pool.PingablePooledConnection.getConnection(PingablePooledConnection.java:309)
at
whatever.XATestSuite.testOpenManyConnection(FbTest.java:29)
...


and this one too:

XADataSource xads = getXADataSource1();
XAConnection xac = xads.getXAConnection();

Connection c = xac.getConnection();
PreparedStatement stmt = c.prepareStatement("select 1 from rdb$database");
stmt.execute();
stmt.close();
c.close();

Connection c2 = xac.getConnection();
PreparedStatement stmt2 = c2.prepareStatement("select 1 from
rdb$database");
stmt2.execute();
stmt2.close();
c2.close();

xac.close();

with this even nastier exception:

org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544569. Dynamic
SQL Error
SQL error code = -502
Attempt to reopen an open cursor
at
org.firebirdsql.jdbc.AbstractPreparedStatement.internalExecute(AbstractPreparedStatement.java:711)
at
org.firebirdsql.jdbc.AbstractPreparedStatement.execute(AbstractPreparedStatement.java:644)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
org.firebirdsql.pool.PooledPreparedStatementHandler.invoke(PooledPreparedStatementHandler.java:172)
at
org.firebirdsql.pool.$Proxy1.execute(Unknown Source)
at
whatever.XATestSuite.testPreparedStatements(FbTest.java:47)
...

Changing the 2nd prepapred statement to "select 2 from rdb$database"
fixes the 2nd issue so that one has to do with prepared statement
cache that gets messed up.

I think the current implementation of wrapped Connection is too weak
and should be reviewed some day.

Ludovic

--- In Firebird-Java@yahoogroups.com, "Roman Rokytskyy"
<rrokytskyy@...> wrote:

>
> Hi Ludovic,
>
> > Setting pooling to true fixes this issue. It looks like the problem
> > comes from the fact that calling connection.close() closes the
> > physical database connection which is incorrect. Only the call to
> > xaConnection.close() should do that which is what is done even when
> > pooling is set to true. That makes me wonder what that pooling
> > parameter is about.
>
> It is exactly about this - to enable connection pooling and it is

set to

> true by default. Switching it off is optional and has exactly the

effect you

> describe. The only bug I see is that we have NullPointerException, but
> should be some SQLException.
>
> > Another quick & easy one:
> > ...
> > In this case, the driver misses a null check that should throw
> >XAException with XAER_RMFAIL.
>
> Thanks!
>
> I will fix both issues before 2.1 release.
>
> Roman
>