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
>