You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Jonathan Moores <jo...@gmail.com> on 2009/01/24 01:17:16 UTC
Transactions and Pooling
Hi,
I was wondering why there is a need to explicitly call
SqlMapClient.endTransaction() in order to return a connection to the pool
even after a commitTransaction()?
I am using Tomcat 6.018 with Ibatis 2.34.726 and I see that the connections
used in a transaction are never returned without the endTransaction() call
which I actually equated to a rollback.
Thanks
Jon
RE: Transactions and Pooling
Posted by Jonathan Moores <jo...@gmail.com>.
But in order to know if something went wrong wouldn't you normally have a
catch block?
Is there some documentation / reasoning on the recommended pattern?
Thanks
Jon
-----Original Message-----
From: Clinton Begin [mailto:clinton.begin@gmail.com]
Sent: zaterdag 24 januari 2009 5:12
To: user-java@ibatis.apache.org
Subject: Re: Transactions and Pooling
The reason is so that you can implement the recommended coding pattern:
try {
// start transaction
// commit transaction
} finally {
// end transaction
}
If you called commit OR end/rollback, you'd have to use a catch
block.... which sux. :-)
Cheers,
Clinton
On Fri, Jan 23, 2009 at 5:17 PM, Jonathan Moores
<jo...@gmail.com> wrote:
> Hi,
>
> I was wondering why there is a need to explicitly call
> SqlMapClient.endTransaction() in order to return a connection to the pool
> even after a commitTransaction()?
>
>
>
> I am using Tomcat 6.018 with Ibatis 2.34.726 and I see that the
connections
> used in a transaction are never returned without the endTransaction() call
> which I actually equated to a rollback.
>
>
>
> Thanks
>
> Jon
Re: Transactions and Pooling
Posted by Clinton Begin <cl...@gmail.com>.
The reason is so that you can implement the recommended coding pattern:
try {
// start transaction
// commit transaction
} finally {
// end transaction
}
If you called commit OR end/rollback, you'd have to use a catch
block.... which sux. :-)
Cheers,
Clinton
On Fri, Jan 23, 2009 at 5:17 PM, Jonathan Moores
<jo...@gmail.com> wrote:
> Hi,
>
> I was wondering why there is a need to explicitly call
> SqlMapClient.endTransaction() in order to return a connection to the pool
> even after a commitTransaction()?
>
>
>
> I am using Tomcat 6.018 with Ibatis 2.34.726 and I see that the connections
> used in a transaction are never returned without the endTransaction() call
> which I actually equated to a rollback.
>
>
>
> Thanks
>
> Jon
Re: Transactions and Pooling
Posted by Chema <de...@gmail.com>.
But, about the docs:
*"The only way to return a connection to the DataSource (or close the
connection) is to call commitTransaction endTransaction()."*
You could return a connection to the pool just with commitTransaction. I
don't know if this would work same way on an EXTERNAL transactional
enviroment.
So. I guess that endTransaction() is a safe method to close connections.
One question. About docs, *"...If you do not explicitly demarcate
transactions using
the startTransaction(), commitTransaction() and endTransaction() methods,
they will all be called
automatically for you whenever you execute a statement outside of a
transactional block ..."*
What does mean that ? Implicitly calling methods just works if
startTransaction() wasn't called ? If you call startTransaction() but not
endTransaction() explicitly, the last one is never called automatically? and
when the thread finishes, Connection object isn't closed in any way ?
Thanks
2009/1/24 Jonathan Moores <jo...@gmail.com>
> Hi,
>
> I was wondering why there is a need to explicitly call
> SqlMapClient.endTransaction() in order to return a connection to the pool
> even after a commitTransaction()?
>
>
>
> I am using Tomcat 6.018 with Ibatis 2.34.726 and I see that the connections
> used in a transaction are never returned without the endTransaction() call
> which I actually equated to a rollback.
>
>
>
> Thanks
>
> Jon
>