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 <[EMAIL PROTECTED]> 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
pgp00000.pgp
Description: PGP signature
