ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Bengl <mar...@dailyspring.net>
Subject Re: Transaction issue with 2.2.0
Date Tue, 27 Feb 2007 20:07:35 GMT
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/transaction.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 <mailto: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 <mailto: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 <mailto: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 <mailto: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