ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rafiq, Adnan" <ara...@carreker.com>
Subject RE: Transaction question
Date Wed, 17 Aug 2005 23:00:13 GMT
A somewhat related question...

We are using Stateless Session beans for transaction management. In this case, is it still
a good idea to code 'daoManager.startTransaction' and other transaction-related methods as
described in the code in the previous mail? We use an XA jdbc driver as there are mutliple
databases involved in a given tx. Currently, we are not calling the daoManager.startTransaction
stuff anywhere in our code.

- Adnan

-----Original Message-----
From: Niels Beekman [mailto:n.beekman@wis.nl]
Sent: Wednesday, August 17, 2005 4:00 PM
To: user-java@ibatis.apache.org
Subject: RE: Transaction question


I'm facing this exact same problem however in a somewhat different
context, see the following archived thread:



I recently restarted my investigation into this problem and have tried
some hacks in the iBATIS code, the changes were made in DaoProxy.java
(which proxies DAO-interfaces to provide transaction-semantics) and
DaoContext.java (which handles the transactions itself). Of course this
is rather messy, but I really do not like the SavePoint-support
mentioned in the thread above, I think it is rather a workaround than a

Anyway, my changes (totally unverified, without any guarantees) in
package com.ibatis.dao.engine.impl:

DaoContext.java, added isTransactionRunning():

public boolean isTransactionRunning() {
  return transaction.get() != null;

DaoProxy.java, modified invoke(): see attached file.

This seems to work pretty good in my case, however further investigation
is required.

I hope the iBATIS devteam can comment on my solution, whether you think
it will work, or when you believe it really sucks :)



-----Original Message-----
From: Barnett, Brian W. [mailto:brian.barnett@pearson.com] 
Sent: woensdag 17 augustus 2005 22:00
To: 'user-java@ibatis.apache.org'
Subject: Transaction question

What are some good options to deal with the following:

public void doSomething() {
	try {
		// Write some stuff to a database
	} catch (Exception e) {
		throw e;
	} finally {

public void doSomethingElse() {
	try {
		ServiceClass1 sc1 = new ServiceClass1();
		// Write some stuff to a database
	} catch (Exception e) {
		throw e;
	} finally {

The doSomethingElse() method will fail because startTransaction() gets
called twice. I need a good way to be able to re-use business logic
in different, or the same, service layer classes.

One thing I have done in the past is create a whole new layer,
essentially a
service delegate, where I have moved all the transaction logic to. I
like that too much because it was just a huge proliferation of methods
to solve the "no nested transaction" problem.

I have also passed flags into methods to indicate if a transaction has
already been started, but passing flags is messy to say the least.

Any great ideas out there?

Brian Barnett

This email may contain confidential material. 
If you were not an intended recipient, 
Please notify the sender and delete all copies. 
We may monitor email to and from our network. 

View raw message