[
http://issues.apache.org/jira/browse/DERBY-2097?page=comments#action_12450918 ]
Daniel John Debrunner commented on DERBY-2097:
----------------------------------------------
I read the above as this new call (say isIdle()) would be used to help manage
the connection pool. This doesn't seem to be valid to me.
Assume the pool thinks the connection can be re-used,then it calls isIdle() and
gets true or false.
- true - ok to re-use
- false - what to do?
* assume the connection is still in use and thus don't return to the pool.
No, if the poolmanager can't determine which connections are
in use or not then it has major problems. The idle connection above could be
in-use and so returning it to the pool would be wrong.
* commit the transaction - Not allowed, can't perform a commit unless the
application says so. (e.g. just hit cancel on an order but the pool commits the
change and thus places the order)
* rollback the transaction - OK, assuming we know the connection is not in
use then it's ok to rollback the work uncommitted by the previous user.
So the only valid choice here is to rollback() the transaction to help manage
the pool. Then since performing rollback() on an idle transaction works just as
well as calling it on an active transaction, then I don't see any benefit to
such an api.
> Requesting a way (API call?) to test an existing embedded XA connection to
> determine if the connection is idle and available for reuse by the connection
> pool.
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2097
> URL: http://issues.apache.org/jira/browse/DERBY-2097
> Project: Derby
> Issue Type: New Feature
> Components: JDBC
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.1.2.1,
> 10.1.3.1
> Reporter: Stan Bradbury
> Priority: Minor
>
> Requesting a way (an API call?) to test an XA datasource connection to
> determine if the connection is idle (no outstanding transactions). This
> would be used for management of an XA connection pool. The test would be
> performed on a connection before it is returned to the pool as available for
> reuse. This would prevent the failure (XAER_OUTSIDE) seen when an active
> connection is incorrectly marked as available and then reallocated for use in
> a new transaction (XA_START).
> In this case the front end exception presented is:
> XAException occurred. Error code is: XAER_OUTSIDE (-9)
> The stack trace produced is:
> javax.transaction.xa.XAException
> com.ibm.db2j.jdbc.DB2jXAConnection.start
> ....XaResource.start
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
