HP3000-L Archives

December 1995, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Larry Boyd <[log in to unmask]>
Reply To:
Larry Boyd <[log in to unmask]>
Date:
Fri, 15 Dec 1995 06:23:18 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (54 lines)
Tom Emerson wrote:
> (snip)
> for the user.  However, if the application allows the user to (1) open
> a dataset & retrieve data, (2) make partial changes to the data, (3)
> prompts the user for more/different data, and at which point (4) the
> user goes out to lunch without "finishing the logical transaction",
> then yes (possibly) the data will be corrupted.
 
and Richard Gambrell wrote:
>Isn't the more "interesting" question what happens to the logical
>transaction?
>E.g. if DBBEGIN has been issued, but not DBEND (before the abort)? Of
>course,
>we have to be actually using DBBEGIN and DBEND for this to matter...
 
Both point out that there is a *tremendous* difference between 'physical'
corruption and 'logical' corruption.  My memory could be failing here
because I haven't used DBBEGIN/DBEND since DBXBEGIN/DBXEND/DBXUNDO became
available.  However, I believe DBBEGIN/DBEND will only help you when you
use DBRECOVER after a failure.  The 'logical' transaction is not
complete without the DBEND, so DBRECOVER will either not make the changes
or back out the changes, depending on whether you are using roll-forward
or roll-back recovery.
 
However, the DBX routines *will* ensure that the 'logical' consistency is
intact as well as the 'physical', *even* if you are aborted.  These
routines not only write log records to the log file, they also trigger
start transactions, end transactions and back-out transactions within XM
(transaction manager).  This means if you call DBXBEGIN, make many
changes (such as described in Tom's post) and get aborted, XM will
automatically back out the complete logical transaction, ensuring
'logical' consistency.  If the DBXEND occurs, the transaction is completed.
 
The DBXUNDO routine was added to allow the programmer to decide whether
or not to continue a logical transaction.  For example, if you call
DBXBEGIN and then allow the user to make several changes as they go
along, often programmers like to ask something like "Update records
(Y/N)?", "Post changes (Y/N)?" or something that means "OK, are you sure
you want me to make the changes you just requested?".  If the user enters
"N", then a single call to DBXUNDO will back out all of the changes since
the DBXBEGIN.  With "Y", just call DBXEND.
 
I don't have my LaserRom with me, but the IMAGE manual has a good chapter
on logging and will explain in more detail (and possible more correctly
with the DBBEGIN/DBEND) how IMAGE logging works.  Again going with my
memory, I think it's chapter 7 or 11 (or am I thinking about my last trip
to Vegas?:)
 
Of course, this only works with IMAGE.  Flat files and KSAM files that
are used in the application still need to be handled by the programmer.
 
--------------------------------------------------
Larry Boyd    <[log in to unmask]>

ATOM RSS1 RSS2