I have a remote client with several threads which all run
(remote) user transactions at a JBoss server.
(The transactions are demarcated at the client side.)
Every transaction invokes serveral remote method calls
of a stateless session bean which in turn
execute SQL-statements of an XA-JDBC-datasource.
The related JDBC connections are handled (properly) by the JBoss-Tx-Manager via XAResources.
However, when I close an aquired connection inside a bean method
it seems that the related JDBC-transaction is implicitly committed,
altough the user transaction is not yet committed (by the remote client).
This causes consistency problems.
On the other hand, if I leave the connection open, the JBoss
CachedConnectionManager complains about not closing the connection
on time (it is only a debug-warning though).
So my question: when and how should I close a related DB connection?
After committing or (right) before committing the User transaction?
Closing after the commit would mean that I needed an extra remote
call just for the connection.close() operation :(
If I make the CachedConnectionManager do the "connection
close job" (which is not clean/standard compliant) the system
seems to quickly run out
of pooled connections. This already happens with only 5 client threads,
which means 5 concurrent user transactions.
Or is there a smart way to configure JBoss and the internal
connection manager for that purpose?
Greetings and thanks for your time,
PS: I use JBoss 3.2.3 an MySQL with an older XA-enabled JDBC driver.
thanks to Adrian(@jboss.org) I have resolved the issue.
I was wrong in assuming that closing a managed connection
would commit an underlying DB transaction.
Sorry for bothering the newsgroup.