I'm a developer in the HSQLDB Development Group. An associate and I have
made an XADataSource according to the javax.sql API spec and chapters 11
and 12 of the JDBC 3.0 Spec, but it is not working with JBoss. I have put
a lot of work into this, and I would greatly appreciate any advice or
assistance to help get it working.
According to the JBoss JCA FAQ, JBoss should drive "custom/thirdparty"
XADataSources "using the standard api". But the pooling callback mechanism
isn't working. I see that JBoss registers its ConnectionEventListeners as
it should, but it is impossible for my JDBC Driver's Connection
implementation to do its part, because
org.jboss.resource.adapter.jdbc.WrappedConnection seems to intercept
end-user calls to close(). My problems are specifically with javax.sql
pooling, not with XA-related classes, but if I understand the docs, JBoss
does not support straight javax.sql pooling other than through the
XAConnection subinterface. It would be great if I could work on the
PooledConnection problems directly without the unnecessary complexity of
Quoting the relevant statements from the JDBC spec:
The driver invokes the ConnectionEventListener methods
connectionClosed and connectionErrorOccurred when the corresponding
events occur. [Impossible for me to do if my driver's
Connection.close() is never invoked.]
The application server calls the method
PooledConnection.getConnection to get a logical Connection object...
The logical Connection object is returned to the JDBC client.
[JBoss is not returning my logical Connection object to the JDBC
client, but it's own WrappedConnection].
Here is exactly what I see:
In a JSP page, I get a UserTransaction from JNDI, get a Connection
from my XADataSource, execute some SQL, commit ut, close connection;
repeat. The connections are ConnectionWrappers holding Connection
instances from my driver. The Connections are "pooled" in that my
second getConnection reuses the physical connection from the first--
but the connection is not reset in between as it should be, because
my driver was never informed about the JSP's Connection.close().
The second JDBC session is the same as if I had continued to use
the original connection, instead of closing and re-opening (a bad
thing since Schemas and various back end resources need to be reset).
I then bypassed your ConnectionWrapper's interception of
Connection.close() by extracting my "logical Connection" from your
wrapper and invoking close() on that (as the JDBC spec says to do in
the second quote above). My JDBC driver then invokes your
connection manager's connectionClosed() method, as it should. But
your connection manager does no pooling in this case. According to
the JDBC Spec, the connection manager uses connectionClosed() to
find out that a LOGICAL connection is closed and then should use
its pooling algorithm to determine whether to reuse a connection or
get another physical connection from the ConnectionPoolDataSource or
XADataSource. Again, from the JDBC 3.0 Spec:
When the JDBC application closes its logical connection, the
JDBC driver notifies the connection pool manager (the listener)
by calling the listener's implementation of the method
connectionClosed. At htis point, the connection pool manager
can return the PooledConnection object to the pool for reuse.
but no connections are ever reused. Every time I run this modified
JSP (which avoids ConnectionWrapper's close() interceptions), your
connection manager requests two additional XA/PooledConnections
(which correspond to physical connections).
I don't know of any open source xa jdbc connection pooling so this certainly is not something we have tested against. I would say either we come up with a testcase using your driver or a mockup to validate the connection pooling expectations. In terms of your particular questions I'll have to look into the the details. Where can the source and *-ds.xml you are using to test this be obtained from?
The source code is in the pooling source code directory for the hsqldb-dev3 CVS module.
You can get it via anonymous CVS like:
cvs -d:pserver:email@example.com:/cvsroot/hsqldb login
cvs -d :pserver:firstname.lastname@example.org:/cvsroot/hsqldb co -P -d hsqldbpooling hsqldb-dev3/src/org/hsqldb/jdbc/pool
I'm posting my -dsi.xml file and test JSP client for you at
Let me know if you want my assistance with the JBoss side. I could, for
example, write a vendor-independent connection manager that can handle
any proper javax.com.ConnectionPoolDataSource implementation (probably
including Apache DBCP's DriverAdapterCPDS class). JCA interfacing would
be outside of my area of expertise, though, as would the server-side
transaction manager work (like enlisting the individual Xids into one
global transaction, handling rollbacks, etc.). I wouldn't spend the time to learn
these new areas without some assurance that the end product would eventually
make it into production. But no problem for JDBC conformance work, or the
actual connection pool management.
I see some demand in this and other forums for JBoss to support
ConnectionPoolDataSources generically, as well as third-party connection
pool managers. If you intend to support these, it would make sense to
tackle them before generic XADataSource support.