Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Transaction question
Date: Wed, 17 Aug 2005 18:00:13 -0500
Message-ID: <745691AF0880C64E8F02CFB140A3872D45E542@DALEXC05.carreker.com>
Thread-Topic: Transaction question
Thread-Index: AcWjaFgCbjyJVd0jTAiNUHDTQHRp9wAAyLoQAATjwzA=
From: "Rafiq, Adnan" <arafiq@carreker.com>
To: <user-java@ibatis.apache.org>

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


Hi,

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

http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/msg025
80.html

http://www.mail-archive.com/user-java@ibatis.apache.org/msg00036.html

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
solution.

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() !=3D 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 :)

Greetings,

Niels

-----Original Message-----
From: Barnett, Brian W. [mailto:brian.barnett@pearson.com]=20
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:

ServiceClass1
public void doSomething() {
	try {
		daoManager.startTransaction();
		// Write some stuff to a database
		daoManager.commitTransaction();
	} catch (Exception e) {
		throw e;
	} finally {
		daoManager.endTransaction();
	}
}

ServiceClass2
public void doSomethingElse() {
	try {
		daoManager.startTransaction();
		ServiceClass1 sc1 =3D new ServiceClass1();
		sc1.doSomething();
		// Write some stuff to a database
		daoManager.commitTransaction();
	} catch (Exception e) {
		throw e;
	} finally {
		daoManager.endTransaction();
	}
}

The doSomethingElse() method will fail because startTransaction() gets
called twice. I need a good way to be able to re-use business logic
methods
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
didn't
like that too much because it was just a huge proliferation of methods
just
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?

TIA,
Brian Barnett

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