Dennis Cote <[EMAIL PROTECTED]> wrote: Ramon Ribó wrote:
>
>
> Imagine one application that can import data from a file. You want
> that, in case of computer crash, either all the data of the file is
> imported or none. At the same time, you want the user to manually
> accept or reject every section of the file.
>
> This example can be modelled in a very natural way with a
> transaction covering the full file import and a nested transaction
> covering every section.
>
>
Ramon,
I don't see that where nested transactions are needed for this example.
You seem to be suggesting a loop reading each file section and writing
it into the database in a nested transaction and then rolling back a
nested transaction if the user says they want to skip that section.
begin
for each section in file {
read section
begin nested
insert section
if promp_user(section) == keep
commit nested
else
rollback nested
}
commit
The same thing can be done far more efficiently by prompting the user
first and only inserting the sections the user wants to keep.
begin
for each section in file {
read section
if promp_user(section) == keep
insert section
}
commit
If the program completes all users selected sections are inserted into
the database atomically. If the program crashes the entire file will be
deleted when the incomplete transaction is rolled back. Similarly if an
I/O error occur when reading the file or a disk full condition happens
when inserting a section, those and any other errors would cause the
transaction to be rolled back so that none of the file sections are
inserted. I want to insert all of the user selected sections or none of
them.
Nested transaction only create more work and make the application more
complicated.
Dennis Cote
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
Denis,
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.
The examples given thus far are not very compelling for savepoints. But
savepoints are usefull in special situations.
Instead of Nested Transactions, What about the concept of an autonomous
transaction?
Regards,
Ken
