[
https://issues.apache.org/jira/browse/IBATIS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clinton Begin closed IBATIS-462.
--------------------------------
Resolution: Won't Fix
Assignee: Clinton Begin
we do as much as is possible to ensure that your connections are closed etc.
You are solely responsible to ensure you're using the correct start/commit/end
pattern. commit can't close the connection, as many people commit more than
once in a single transaction scope.
> Nested Transaction or Without commitTransaction
> -----------------------------------------------
>
> Key: IBATIS-462
> URL: https://issues.apache.org/jira/browse/IBATIS-462
> Project: iBatis for Java
> Issue Type: Bug
> Affects Versions: 2.0.8
> Environment: WebSphere,RAD,iBatis 2.0.7
> Reporter: Chirag
> Assignee: Clinton Begin
> Priority: Blocker
>
> iBatis documentation says:
> Note! Transactions cannot be nested. Calling .startTransaction() from the
> same thread more than once,
> before calling commit() or rollback(), will cause an exception to be thrown.
> In other words, each thread can
> have -at most- one transaction open, per SqlMapClient instance.
> Note! SqlMapClient transactions use Java's ThreadLocal store for storing
> transactional objects. This means
> that each thread that calls startTransaction() will get a unique Connection
> object for their transaction. The
> only way to return a connection to the DataSource (or close the connection)
> is to call commitTransaction()
> or endTransaction(). Not doing so could cause your pool to run out of
> connections and lock up.
> Issue:
> Our requests were failing intermittently because it was going to different
> schema and returning null resultMap. We found this issue when lot of people
> started testing.
> We fixed by making following changes.
> 1) We had clientDAOManager.commitTransaction() and there was no
> clientDAOManager.endTransaction() after that. We did not need commit, so we
> removed that and added clientDAOManager.endTransaction()
> 2) We removed nested transaction.
> Looks like both of the issues should have been handled by iBatis. We did not
> get exception for nestedTransaction.
> commitTransaction should have returned connection to the pool gracefully even
> if endTransaction was not called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
