On Tue, 30 Sep 2008, Graham Leggett wrote:
Thomas Fischer wrote:
I am not really qualified to answer this, because I do not know how JTA
works internally. So use healthy scepticism with the answer below.
With all external transaction frameworks, the problem is that at the
moment, Torque does not have a "Transaction Info" object which is passed
around in a transaction, it only passes a jdbc connection around (There is
a Transaction object but it does not contain information about the current
transaction). So the problem is that there is not really a way to pass
transaction info around.
But maybe one can use a custom Data source providing a custom Connection
wrapper object which contains the connection information and the
transaction information. This would probably mean some ugly casts, and
patches to the Torque Transaction object, but perhaps it could work.
Again, this comes with the disclaimer that it's what I've figured out so far.
From what I have managed to gather so far is that jta works by requesting
callbacks with the JDBC driver, and this means you don't need to explicitly
pass around any connection object representing the transaction, the
transaction is associated with the thread in which you're running.
Does this mean that it is even an error to pass the connection around ???
All the developer needs to do as I understand it, if using the
UserTransaction interface, is to call the begin(), commit() and rollback()
methods to signal to jta whether you are done or not.
The underlying JDBC callbacks will be called to rollback a failed transaction
if necessary, the caller doesn't need to worry about it.
From the looking at the generated torque source, if you pass null as a
Connection, torque will ignore all transactions, which is exactly in theory
what jta wants torque to do.
No. Torque will open a transaction for every operation. Look at the code
for BasePeer.doSelect():
public static List doSelect(Criteria criteria) throws TorqueException
{
Connection con = null;
List results = null;
try
{
con = Transaction.beginOptional(
criteria.getDbName(),
criteria.isUseTransaction());
results = doSelect(criteria, con);
Transaction.commit(con);
}
catch (TorqueException e)
{
Transaction.safeRollback(con);
throw e;
}
return results;
}
It gets a connection in Transaction.beginOptional() (this is fine), does
the db operation, and then either commits or rollbacks (which is bad, if
your understanding is correct)
So I'd rather go for explicit transaction handling (passing a connection
around), because this allows control over rollbacks or commits. You just
need to make sure that the connection object which you pass around is not
a "real" connection. An idea to achieve this would be as follows:
Create a fake connection, which implements the connection interface, and
which has a reference to the real data source. For every operation
required from the fake connection, it goes to the pool, retrieves a
connection, does the operation and returns the connection. Then create a
fake data source which has a link to the real data source and creates the
fake connections, and configure Torque to use the fake data source.
This way you do not pass around a real connection, and you don not let
Torque issue automatic commits or rollbacks to the connection.
The solution sounds a bit mad, but I belive it could work without
even patching the Torque source code.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
