I have seen broken chains in the past couple of years. Some were traced to
a defect in DBGENERAL which has since been fixed. Others did not have a
clear cause but this was on a machine that eventually had to be replaced
because of hardware problems.
----- Original Message -----
From: "Gibson Nichols" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Monday, August 06, 2001 2:30 PM
Subject: Re: Does ABORTJOB cause Image broken chains?
> I've seen six broken chains(different systems all on 6.0) in the past
twelve
> months.
>
>
> "Gavin Scott" <[log in to unmask]> wrote in message
> news:9kfbe90j4n@enews2.newsguy.com...
> > > A programmer asked me if doing an ABORTJOB on a program will
> > > cause a broken chain in an Image database.
> >
> > It's amazing how much superstition exists surrounding this kind of
stuff,
> > and how many unnecessary rituals and sacrifices are performed daily to
> > appease the mythical pantheon of data integrity gods.
> >
> > "Real" broken chains are (supposed to be) *impossible* to achieve with
> Image
> > on MPE/iX, no matter what application programs do, or how they are
> aborted,
> > or how many times the system crashes!
> >
> > The Transaction Manager (XM) provides absolute protection against
internal
> > database inconsistencies, as long as there are no bugs in the system and
> as
> > long as the hardware is not corrupting data. No action or configuration
> is
> > required on the part of the user.
> >
> > Logical inconsistencies (order detail without an associated order header
> > record for example) can easily be created by aborting an application
> that's
> > in the middle of performing a database update that spans multiple
records.
> > Of course Image doesn't care whether your data is logically correct or
> not,
> > that's the job of application programmers.
> >
> > Using DBBEGIN/DBEND will have no affect on logical integrity whatsoever,
> > unless you actually run DBRECOV to roll forward or roll back the
database
> to
> > a consistent point *every time* you abort a program or suffer any other
> > failure.
> >
> > By using the DBXBEGIN/DBXEND "XM style" transactions, you can extend
> Image's
> > guarantee of physical integrity to the logical integrity of your
database.
> > The system will ensure that no matter what happens, either all changes
> > inside a DBX transaction will be applied, or none of them will be. Of
> > course it's still possible to use this feature incorrectly (locking
> > strategies are non-trivial as you need to lock the data that you *read*
as
> > well as that which you intend to write in many cases).
> >
> > MPE/V introduced a feature called Intrinsic Level Recovery (ILR) which
> could
> > (and still can be) enabled for a database. This was sort of a mini-XM
> which
> > forced updates to disk each time an Intrinsic call completed in order to
> > ensure structural integrity of the database in the face of system
> failures.
> >
> > I believe that on MPE/iX, enabling ILR for a database does something
> really
> > nasty like forcing an XM post after every update intrinsic call, which
is
> a
> > serious performance problem. ILR is no longer required on MPE/iX as XM
> will
> > ensure integrity without it. With ILR you might be guaranteed that
every
> > committed transaction will survive a system abort, whereas without it XM
> > might end up having to rollback the last fraction of a second's worth of
> > transactions. For almost any application this difference is negligible.
> Do
> > not turn ILR on!
> >
> > There are more complexities if your application performs transactions
that
> > affect multiple databases or databases and non-database files. It's
> > possible to do multi-database Image transactions, but only if the
> databases
> > reside on the same volume-set I believe.
> >
> > G.
> >
> > * 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 *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
