Forum OpenACS Development: Re: db_transaction side effects

Collapse
12: Re: db_transaction side effects (response to 11)
Posted by Nis Jørgensen on 06/02/06 10:29 AM
Malte, some of us have use cases for "real" nested transactions. Specifically, situations where the statement "After all, when I am in a db_transaction I want to reroll everything if it fails at one point and not each transaction separately." is false.

However, the Postgres branch of the db_api currently DOES NOT SUPPORT THESE. You can nest calls to db_transaction, but they don't actually do anything to the database. So it is not really clear what you are asking for with the "do not execute another db_transaction".

It seems you have an idea that using nested transactions are bad, something to be avoided. In my mind, they should be correctly implemented and used.

I am opposed to your idea of letting the caller decide whether he wants a transaction or not. This is an implementation decision, and shouldn't be exposed in the api.

Collapse
13: Re: Re: db_transaction side effects (response to 12)
Posted by Malte Sussdorff on 06/02/06 11:18 AM
My assumption is that having multiple levels of db_transaction nested into each other currently stumbles over its own feet from time to time. Otherwise I could not explain the behaviour which started this thread. My suggestion was a "quick fix" to the problem derived from the fact that it happens at least 3-4 times a day in a production environment and I am not really keen on trying to fix the db_api where I do not even have a clue where to start.

So my assumption is we are talking about different things. I would be opposed to the idea of the caller deciding if a transaction should happen or not, could I be sure that having multiple nested transactions (and we are talking about 4 levels of procedure calls where each procedure has at least one db_transaction in them, sometimes more (e.g. if you call content::item::new and then content::revision::new)) does not make the system stumble.

I got the levels of transactions reduced in one instance and so far I did not get an error from it any more. I would be delighted if I had more scientific proof (e.g. a reproduceable test case) so one could maybe even look in postgres directly what is happening and why. But at the moment I don't.