When getting a connection from a XA datasource retrieved via a JNDI lookup within an ejb, exceptions like in JDBC86 occure. The solution is to
not close the connection (i. e. in a finally block) after finishing the operations. In my opinion, in a managed environment like in an
appsever where connection pooling is used, the close-operation should do nothing and it should definitly not cause an exception.
The text was updated successfully, but these errors were encountered:
Can you describe your configuration? I.e. how did you configure the Glassfish, etc. In general it should be possible to close the connection in a finally block, and in this case connection will be returned back to the pool...
The datasource is looked up by an POJO class via JNDI which lives inside an stateles EJB (in this case I don't use dependency injection).
Inside the class some SELECT-statements are executed and the connection is closed in a finally block.
This szenario gives the same errors like described in JDBC 86. When I remove the code for closing the connection, it runs without problems, but
I don't really feel good with this workaround because the same code is also used outside an JEE container.
It doesn't matter if I use the XA driver or the usual pooling driver. The only driver which works is the org.firebirdsql.pool.sun.AppServerDataSource.
That's why I assume, that the connection is not returned to the pool when it is closed.
When I use the resource adapter (I deployed the RAR into glassfish) and use it as a datasource with XA transactions, it also runs without
Resolved by JDBC176 if you replace the current XADataSource with org.firebirdsql.ds.FBXADataSource. The implementations in org.firebirdsql.pool and org.firebirdsql.pool.sun won't be fixed and may be removed in Jaybird 2.3 or later.