db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <tfisc...@apache.org>
Subject Re: Torque and JTA
Date Tue, 30 Sep 2008 21:52:11 GMT

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;

             con = Transaction.beginOptional(
             results = doSelect(criteria, con);
         catch (TorqueException e)
             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.


To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

View raw message