Thank you for your extensive comment, i appreciate it. The architecture your described
solves the problem. Once interesting thing examining Transactions is the transaction isolation
level. Unfortenately, i was not able to set this on a level (READ_UNCOMMITED) to read
the same resources (that possible, after a rollback, do not exists in the future) which could
also provide a solution (hack) to the problem. I prefered your advise in favour of the latter. (The
only problem i have is having to pass the connection object through my business logic).
Maurice
kean wrote:
this is not nested transaction, this is dead lock situation if you are using the same resources. it's definitely the software architect problem. The way I solved it is always delegate or past in the Connection object whenever you do anything with the database, and let the business object handle the transaction ...
for example ... this is just a simple example I come out here now to illustrate for you, it's not a production code.
//the low level class
class UserCtrl {
public static long addUser(Connection con, String whatever, String groupId) throws WhateverException {
Users user = new Users();
user.setName(whatever);
user.setGroupId(groupId);
user.save(con);
return user.getID();
}
}
class GroupCtrl {
public static long addGroup(Connection con, String whatever) throws WhateverException {
Group group = new Group();
group.setName(whatever);
group.save(con);
return group.getID();
//or you can used the mediator pattern to sovled
//the how to get the group ID
}
//for convenien you might want to do this method
public static long addGroup(String whatever) throws WhateverException {
try {
Connection con = Transaction.begin("hellodatabase");
addGroup(con, whatever);
Transaction.commit(con);
} catch (TorqueException e) {
try {
Transaction.rollback(con);
} catch (Exception ex) {
//oh well, at least we try
} finally {
//new error, throw whatever error here
}
} catch (WhateverException e) {
throw e;
}
} //the high level class, this could be your business logic class
//or the strut action class, and I think this is better to handle
//it in the business object class.
class AddUserBusinesRule {
public void addUser() throws AddWhateverException {
try {
Connection con = Transaction.begin("hellodatabase");
long groupId = GroupCtrl.addGroup(con, "hellogroup");
UserCtrl.addUser(con, "hellouser", groupId);
Transaction.commit(con);
} catch (TorqueException e) {
try {
Transaction.rollback(con);
} catch (Exception ex) {
//oh well, at least we try
} finally {
//new error, throw whatever error here
}
}
}
damn, this is long, anyway, good luck.
kean
Maurice Wijtten wrote:
I'm currently using Torque in my webapplication, and using it from
several points acros my business logic. I'm facing the problem in a
situation that i'm starting a transaction in an (struts) action. Inside the
transaction i have a call to a business object which in my case handles
billing. Inside the billing object, i have created (another?) transaction,
since this object knows nothing about the struts action that is calling it.
At the moment i save a torque object in the second transaction block,
the torque thread completely dies, and my DBA get's furious because
the oracle server is somehow having alot of trouble with it.
My question: Is there something wrong with my architecture (having
some sort of 'nested' transaction, and, is there another solution.
Kinds regards,
Maurice Wijtten
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
