ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Rodenbaugh" <drodenba...@WILDBLUECORP.COM>
Subject RE: Transaction issue with 2.2.0
Date Tue, 27 Feb 2007 20:15:30 GMT
The DAOs do not work on the same tables.  The lock level and isolation
are Oracle defaults.  I never see the exception on the console when the
transaction code is enabled.  Turn off transactions and boom, the
exception is back.  It's like the iBATIS DAO transaction manager is
hanging on to something...
 
-D

________________________________

From: Martin Bengl [mailto:martin@dailyspring.net] 
Sent: Tuesday, February 27, 2007 1:08 PM
To: user-java@ibatis.apache.org
Subject: Re: Transaction issue with 2.2.0


could it be a "dead lock" problem?
are the different DAOs working on the same tables?
whats the lock level?
which isolation level do you use?

i think this works for two JTA resources without XA (means "Tx code
off")
because there the transaction manager need no two phase commit.


Dave Rodenbaugh wrotes: 

	Yes, I saw the release, just after I had completed
implementation with 2.2.0 libraries.  Migrating to Spring is not the
best option at this time.  We're deep into our project cycle with
release coming in the not-to-distant future...This transaction aspect
has just bitten us as we've written the high-level services that require
transaction handling.
	 
	I never received a timeout...the application just runs and runs
forever.  
	 
	-D

________________________________

	From: Martin Bengl [mailto:martin@dailyspring.net] 
	Sent: Tuesday, February 27, 2007 12:41 PM
	To: user-java@ibatis.apache.org
	Subject: Re: Transaction issue with 2.2.0
	
	
	oh mda in real life project :-)
	you should look for your protection of investment when using
ibatis dao. look at the ibatis homepage: "The Java DAO framework has
been removed from iBATIS as of release 2.3.0. We heartily recommend that
you consider using the Spring Framework <http://www.springframework.org>
for all your DAO needs! Spring offers great support for iBATIS."
	
	spring is not a more heavy weight framework - spring is the
future any java application scenario.
	
	but: Did you get a timeout when the process hangs at
op3UsingBarDao?
	
	greetings
	martin
	
	Dave Rodenbaugh wrote: 

		Well, the answer is that we're code generating these two
separate modules...they have code-generation time differences, but at
runtime, we're sharing the same DataSource for both.  Part of the reason
is modularity of the two, part of the reason is that I'm not in control
of the database design so I'm stuck with it.
		 
		Is there a non-Spring solution that I can use?  I'm not
anxious to introduce another set of libraries that are even more heavy
weight than iBATIS, which is lovely.
		 
		-D

________________________________

		From: Armeanu, Christian [mailto:ArmeanuC@hsd.k12.or.us]

		Sent: Tuesday, February 27, 2007 12:27 PM
		To: user-java@ibatis.apache.org
		Subject: RE: Transaction issue with 2.2.0
		
		

		That is correct.  Why are you using two different
database resources to access the same resource anyway?

		

		Chris

		

		

		
________________________________


		From: Martin Bengl [mailto:martin@dailyspring.net] 
		Sent: Tuesday, February 27, 2007 11:22 AM
		To: user-java@ibatis.apache.org
		Subject: Re: Transaction issue with 2.2.0

		

		yes, thats correct - you should use the spring
transactional support. If you are using only one database resource (only
one oracle database for example) you needn't XA. you can use local jdbc
transaction with spring.
		
		see
http://static.springframework.org/spring/docs/2.0.x/reference/transactio
n.html for more details
		
		greetings
		martin
		
		Armeanu, Christian wrotes: 

		I don't know about the transaction support with iBATIS
DAO, but if you could the recommended Spring DAO for example.  All you
would need to do is to configure the appropriate transaction manager.  

		

		Chris

		

		
________________________________


		From: Dave Rodenbaugh
[mailto:drodenbaugh@WILDBLUECORP.COM] 
		Sent: Tuesday, February 27, 2007 10:52 AM
		To: user-java@ibatis.apache.org
		Subject: RE: Transaction issue with 2.2.0

		

		If this is the answer, how does iBATIS support XA
transactions?  Do I need to use a different Oracle library, or configure
this differently?  I'm not an XA expert...

		

		Thanks,

		-D

		

		
________________________________


		From: Armeanu, Christian [mailto:ArmeanuC@hsd.k12.or.us]

		Sent: Tuesday, February 27, 2007 10:12 AM
		To: user-java@ibatis.apache.org
		Subject: RE: Transaction issue with 2.2.0

		For all I know you need XA transactions for this to
work...

		

		Chris

		

		
________________________________


		From: Dave Rodenbaugh
[mailto:drodenbaugh@WILDBLUECORP.COM] 
		Sent: Tuesday, February 27, 2007 9:07 AM
		To: user-java@ibatis.apache.org
		Subject: RE: Transaction issue with 2.2.0

		

		Oh...one other piece of possibly relevant info:

		

		FooDao and BarDao are created in two separate JARs, each
having their own configuration properties (they point to the same DB,
but different schemas.  They share the same runtime user information).

		

		Thanks,

		-D

		
________________________________


		From: Dave Rodenbaugh 
		Sent: Tuesday, February 27, 2007 10:05 AM
		To: 'user-java@ibatis.apache.org'
		Subject: Transaction issue with 2.2.0

		Hello,

		

		I have a question about a transaction scenario I'm
doing...I see problems when trying to use
startTransaction()/commitTransaction()/endTransaction with JDBC data
source.  I'm using Oracle 9.2 client libraries, and this is with
iBATIS-2.2.0.

		

		Here's my code pattern--I have two Daos involved--one
"Foo" and one "Bar".  I'm transacting Foo here.  (I've tried transacting
both and get the same result, too--so it seems to be relating to the
FooDao transaction somehow)

		

		DaoManager dm = FooDaoManager.getDaoManager();

		try

		{

		    dm.startTransaction();

		    op1UsingFooDao();

		    logger.info("1");

		    op2UsingFooDao();

		    logger.info("2");

		    op3UsingBarDao();                  //throws
SQLException when the Tx code is off, hangs here when using Tx

		    logger.info("3");    //never gets here...

		    dm.commitTransaction();

		}

		finally

		{

		    logger.info("Inside finally block");

		    dm.endTransaction();

		}

		

		Output with no transaction code (application
terminates):

		1

		2

		Inside finally block

		

		Output with transaction code present (application
hangs):

		1

		2

		

		I expected that the transaction would roll back when an
exception was encountered by triggering the finally code.  However,
since it hangs, I don't know where or why it hung in
op3UsingBarDao()...?

		

		What am I doing wrong in this scenario and how should I
correctly address this?  This scenario is consistent with the
documentation, but the docs don't cover multiple DaoManager
transactions...

		

		Thanks,

		-Dave

		




Mime
View raw message