HP3000-L Archives

July 2003, Week 2

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:
Dennis Hassell <[log in to unmask]>
Reply To:
Date:
Thu, 10 Jul 2003 14:49:53 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (84 lines)
This answer completely depends on what "logically consistent" means.
Many of the transactions I see on Image databases are fairly simple and
would involve a single DBPUT, DBDELETE, or DBUPDATE. For those, there is
no difference if you put a DBBEGIN or DBEND around them. The recovery
and analysis utilities will react the same. This includes changing a
value in a detail with an automatic master - the master and the detail
will be part of the same transaction, just like the DBPUT will update
both the master and the detail.

One common update which does need a DBBEGIN/DBEND wrapper is a put of a
detail record with a manual master key entry which does not exist, so a
put on the master plus a put on the detail are required to be
consistent. Similarly with a delete where the manual entry should also
be deleted because it's chain length is now zero. Another transaction
along the same line is a change of a key field, where a put plus a
delete are required for an automatic master, and 1-2 puts plus 1-2
deletes are needed for a manual master, depending if the manual master
entries already exist or not, and if the old manual master entry needs
to be deleted or not.

As databases have become more complex and people have been doing more
third order normalization of the database structures, it's been more
common to need to do multiple puts, deletes, and updates in a "logical"
transaction.

For whatever reason, if there are multiple steps in your DB
put/delete/update transaction, then you would need to encapsulate the
various steps in a DBBEGIN/DBEND wrapper. Then, the recovery utilities
will keep and apply a consistent transaction and will ignore a
transaction with only a DBBEGIN but no DBEND, thus avoiding the partial
(inconsistent) change being applied.

Dennis Hassell
Dennis Hassell and Associates
(941) 746-4919
(941) 224-3981 - cell


-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of John Clogg
Sent: Tuesday, July 08, 2003 4:36 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] image logging question

Well, if you want your databases to be logically consistent after a
system crash, you'd better use DBBEGIN/DBEND or DBXBEGIN/DBXEND.
Without them you run the risk of partially-completed logical
transactions being left in that state.  The consistent states the manual
refers to are physically consistent, but not necessarily logically
consistent.  Of course, this does not mean you have to apply begin/end
pairs in every case -- only to those logical transactions that comprise
multiple physical updates.

-----Original Message-----
From: John Penney [mailto:[log in to unmask]]
Sent: Tuesday, July 08, 2003 1:18 PM
To: [log in to unmask]
Subject: Re: image logging question


Donna:

Nay, not so: you do not have to explicitly code the 'DBBEGIN' and
'DBEND'
in your code- can you imagine the amount of work you'd face to do that?!

To quote RTFM:"If logging is specified and DBEGIN/DBEND (static
transactions) or DBXBEGIN/DBXEND (dynamic transactions) are not used,
TurboImage/XL considers each DBPUT, DBDELETE, and DBUPDATE to be a
single logical transaction. While a transaction is executing, the
database is considered to be in an inconsistent state. Thus, each
transaction takes the database from one consistent state to another. p
7-8 TurboIMAGE/XL manual - my emphasis added.


<Snipped Donna's original post>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2