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:[EMAIL PROTECTED]
*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:[EMAIL PROTECTED]
*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:[EMAIL PROTECTED]
*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:[EMAIL PROTECTED]
*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:[EMAIL PROTECTED]
*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
