cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: transactions in the SQLTransformer
Date Wed, 14 May 2003 20:59:58 GMT
Brian Johnson wrote:
> Interesting.... maybe it's an issue with XA vs. non-XA transactions. I 
> haven't had the problem you describe with XA transactions. 

Ok, I see, I'm using MySQL and naivly believed that most DB:s have 
transaction mechanisms that is like the (non-XA) transactions there. In 
MySQL you write e.g.

SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summmary=@A WHERE type=1;

and if you do that in the SQLTransformer each statement must be done 
within a new query element, and if each query element gets a new (or 
old) connection from the pool, about anything can happen, the statements 
in the transaction can be intermingled with statements from another 
user. If you have some kind of unique identifier for the transaction, 
which you, IIUC have for XA-transactions, nothing of this should be any 
problem for you.


> In my 
> application, you would have to associate the connection with the 
> session, since the SQLTransformer is used multiple times in the pipeline 
> in a single transaction. What database are you using? I believe that 
> transactions are associated with a particular thread, and since a second 
> user request will always come in on a different thread, it shouldn't be 
> an issue. Am I missing something? Is there a difference between XA and 
> non-XA on this issue? Am I just wrong and simply haven't noticed the 
> issue in my app? I wrote a test case for my application that I believe 
> addresses the issue, but maybe I need to increase the number of 
> concurrent connections to properly test it. Thanks.
> Brian
> On Wednesday, May 14, 2003, at 07:45  AM, Daniel Fagerstrom wrote:
>> Brian Johnson wrote:
>> > It should not be necessary to use the same connection for each query.
>> > Even if you are not using a J2EE datasource, Cocoon maintains a pool
>> > of database connections, so the connection is not actually closed
>> > after each query. Transaction processing does not require a single
>> > database connection, the only thing it requires is a single thread.
>> I have tried this, IIRC it lead to some highly undesirable things like
>> that an SQLTransformer instance that was serving another users request
>> got a connection with an opened transaction from the pool and closed it.
>> As soon as you have more than one user it is very dangerous to return a
>> connection with an opened transaction to the pool, you might be lucky
>> and get the same connection when you executes the rest of the queries in
>> the transaction. But this "luck" is more likely when you as a developer
>> is the only user.
>> Anyhow as I wrote earlier in this thread I have written a patch
>> that solve the
>> problem, and also increase the efficiency of the SQLTransformer, and
>> that works without any problems in our production systems since a couple
>> of mounths. I would be very thankful if somebody with commit right could
>> find the time to apply the patch :)
>> /Daniel

View raw message