cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Johnson <brian.john...@vitiro.com>
Subject Re: transactions in the SQLTransformer
Date Wed, 14 May 2003 22:58:18 GMT
Ok, gotcha. I believe that if you have a transaction manager (jboss for 
instance), you can do thread based transactions with non-XA databases. 
The only difference would be that you couldn't use multiple databases 
in the same transaction... I could be wrong though... You could extend 
the SQLTransformer and do start/commit on the transaction manager. I'm 
calling cocoon using iiop, so I use it as is. It's probably overkill 
for what you're doing though.
Brian

On Wednesday, May 14, 2003, at 04:59  PM, Daniel Fagerstrom wrote:

> 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.
>
> START TRANSACTION;
> SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
> UPDATE table2 SET summmary=@A WHERE type=1;
> COMMIT;
>
> 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.
>
> /Daniel
>
>> 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
>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=16718 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
>>>
>>>
>>>
>
>


Mime
View raw message