commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asleson, Ryan" <>
Subject DbUtils Transaction Management with Spring
Date Fri, 02 Feb 2007 18:25:02 GMT
I've built a custom DAO framework that relies on DbUtils to do all of
the "heavy lifting" for queries.  DbUtils works great, thanks!
I want to use Spring to manage the database transactions.  I've created
some service beans that use the Spring TransactionInterceptor to start
and stop transactions whenever a method on the service bean is called;
of course, the service beans call the DAOs, so whenever a DAO method is
called there should be a transaction available.
There has been some confusion on our team recently as to whether or not
this will work.  Somebody has noticed that an error occurred and the
transaction was not rolled back; I haven't investigated it completely
myself yet, so I'm not sure of the exact circumstances.  Anyways, said
person became quite concerned and started digging around in the
QueryRunner source code and found this comment by the update() method:
The Connection must be in auto-commit mode or the update will not be
Now we're all confused as to whether DbUtils can play nicely and let
Spring handle the transaction management with commits and rollbacks.  I
suspect it will, but some confirmation from somebody who's used DbUtils
with Spring or a comment from a DbUtils developer will be greatly
appreciated.  In the QueryRunner.update() method, the Connection is
always closed in the finally clause.  Will this *always* commit the
statement, regardless of whether something else (like Spring, in this
case) is managing transactions?
If it helps any, the data source from the application server (WebLogic,
in this instance) which is created by Spring.  The data source is
injected into each DAO via Spring, so DbUtils is always used with a
DataSource rather than an individual Connection.
Any light somebody can shed on the subject is greatly appreciated.
Thank you!!!!

This e-mail message is being sent solely for use by the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.
 If you are not the intended recipient, please contact the sender by phone or reply by e-mail,
delete the original message and destroy all copies. Thank you.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message