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.
