HP3000-L Archives

October 1999, Week 1

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:
"Johnson, Tracy" <[log in to unmask]>
Reply To:
Johnson, Tracy
Date:
Wed, 6 Oct 1999 20:17:43 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (43 lines)
> -----Original Message-----
> From: Gavin Scott [mailto:[log in to unmask]]
>
> Tracy wrote:
> > What will happen is that some NM KSAM files will get posted
> > to and some others will not, depending where the application
> > was at the nanosecond of the crash.  It becomes similar to
> > the old problem of rollback or rollforward recovery for Image.
> > But the NM KSAM files will not be corrupted in themselves,
> > but may be out of sync with other ones that have a common
> > link or field as defined by the application.
>
> Since NM KSAM files are attached to the Transaction Manager,
> all modifications to NM KSAM files (on the same volume set!) will
> be committed in the order the updates were performed.  So if you
> write to NM KSAM file A then NM KSAM file B, then the system fails,
> you can be assured that if the update to B survives then the update
> to A must also have survived.
>
> The same thing applies to updates done to Image databases on the same
> volume set, i.e. that updates to them will be serialized with respect
> to each other and to other Image databases and NM KSAM files (and any
> other entities attached to XM) on THAT SAME VOLUME SET.
>
> This makes it possible to build your own robust transaction processing
> applications and implement your own two-phased commit logic, etc.
>
> If, however, you have part of your data involved in a "transaction" on
> one volume set, and other data involved in the same transaction on a
> different volume set, and the machine fails, then there is NO
> GUARANTEE
> WHATSOEVER about what order the updates may be committed in.  So you
> don't want to put logically related databases on different volume sets
> because it can introduce logical inconsistencies into your data (after
> a system abort) which were not possible when all the data was on the
> same volume set.

To carry out Gavin's example further, if NM KSAM files A and B are
updated, then it crashes before the application updates NM KSAM file C.
You'll WILL have an inconsistent set of files (no matter whether they
are on the same Volume Set or not.)  However these independent NM KSAM
files will be good in and of themselves since they won't corrupt.

ATOM RSS1 RSS2