ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lamey <cla...@localmatters.com>
Subject Re: Performance question
Date Thu, 10 Jan 2008 21:19:37 GMT
On 1/10/08 1:58 PM, "Brian Parkinson" <parki@avaning.com> wrote:

> Hi Christopher -
> Finally got a chance to look at adding transaction support to my iBATIS
> code using Spring 2.5.1.
> Needed to use spring.jar as well as aspectweaver.jar.

Yea, it needs that jar for the AOP stuff.
Your config looks ok.

> 1. Is this it? Seriously - how incredibly painless!!!

There's a reason Spring is so widely used, eh?

> 2. Can you see anything that's missing? I'm using the apache commons
> dbcp BasicDataSource, and so with this setup, I'm
> looking good to have connection pooling as well as transaction support.

I use DBCP just like that, so it should work.  If you're paranoid, you can
check the number of connections against your db - it should match the min
connections specified for DBCP.

Another thing you can do is enable JDBC logging with iBATIS.  Set java.sql
category to DEBUG level in your log4j config and you can track connections
being used and released.  Don't leave it at DEBUG for any performance runs
though, it writes out a ton of messages.

> 3. Given that there is transaction support, then I'm assuming that both:
> getSqlMapClient().startTransaction();
> and
> getSqlMapClient().startBatch();
> will be properly honoured.

Actually, they won't.  The Spring SqlMapClientTemplate essentially does a
no-op on these calls - it assumes an external transaction manager will
handle everything for you outside of the code.  So what you can do is just
remove them from your code (including the commit and finally {
endTransaction }).

With the Spring declarative transaction handling, you can assume that those
are being called for you.  And if you chain methods that meet the pointcut
criteria, they will be wrapped in the same transaction as the calling method
- pretty neat stuff.

When starting out, I usually stick this in the middle of my method after a
couple inserts that I know will write data:

if (true) {
    throw new RuntimeException("Force exception to test rollback");

That way I verify the inserts before the exception rollback correctly.


View raw message