Ken wrote:
Correct me if I'm wrong on this concept:
Adding nested transactions really means adding the ability to demark internally a transaction ID. So that later that transaction can be rolled back.
Consider
begin Main;
step a
savepoint loc1
step 1
savepoint loc2
step 2
rollback loc2 <----- Rolls back step2
step 2a
savepoint loc3
step 3
commit ;
(result: step a, step 1, step2a and step3 )
I think the concept of a savepoint is simpler than a truely nested transaction. As one doesn't actually need to start a new transaction just mark a position where a savepoint rollback would stop. Savepoints then are not really nested transactions but just markers that indicate when to stop rolling back within the journal file.
Ken,
As far as I understand it the two concepts are fundamentally the same.
Savepoints can be implemented using simply nested transactions. The
savepoint syntax is what is used by the SQ:1999 and later standards.
But savepoints are usefull in special situations.
Yes they are, but those situations are really quite rare in the real world.
Instead of Nested Transactions, What about the concept of an autonomous transaction?
I don't know what you mean by autonomous transactions as opposed to
normal SQL transactions. Can you explain the difference?
Dennis Cote
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
