On Wed, Jan 14, 2004 at 04:45:46PM +0700, Chris Travers wrote:
> Ok. Now I am confused. I thought that a nested transaction would involve
> two features:
> 1: The ability to incrimentally commit/rollback changes, i.e. at certain
> points in the transaction have a sub-commit.
I think they're referred to as savepoints, not sure. I think they become
trivial once nested transactions are done.
> 2: The ability to have a transaction within another transaction with
> transactional visibility rules applying within the transaction tree.
>
> What exactly do you mean by roll back individual statements? What exactly
> would be the default behavior?
Well, one of the problems people would like to solve is that if a trigger or
constraint fails then it doesn't roll back the whole transaction. The way
this would be acheived is by making every statement within the parent
transaction it's own implicit subtransaction so any errors can be caught and
undone cleanly.
This would mean that even normal transaction blocks that people do now could
involve dozens of subtransactions, especially if you start involving
triggers and function calls.
In any case, I don't quite understand the intended semantics of "duplicate
key shouldn't rollback transaction". If I call a function that inserts a
duplicate key, should the other effects of the function be rolled back or
not? Anyone know how MSSQL deals with this?
> Then you might have to have an array of "related transactions" which are
> also visible for each thransaction, sort of like a tree with bidirectional
> links. Unfortunately I can imagine this being a source of subtle, hard to
> troubleshoot bugs. Something like
> _x_id, _x_status, related_x_id[], child_x_id[], so that a rollback can
> rollback all child_x_id's without touching the other transactions which are
> parents, cousins, etc. but visible.
The issue is atomicity. You need to be able to make sure that even if the
power fails halfway through a write that the whole transaction is either
committed or it's not. The mrore you have to update the harder it gets.
Anyway, far more intelligent people than I have been over this, check the
archives of this list and -hackers.
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> (... have gone from d-i being barely usable even by its developers
> anywhere, to being about 20% done. Sweet. And the last 80% usually takes
> 20% of the time, too, right?) -- Anthony Towns, debian-devel-announce
