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]
-----------------------------------------------------------------------------
