HP3000-L Archives

November 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:
Roy Brown <[log in to unmask]>
Reply To:
Roy Brown <[log in to unmask]>
Date:
Thu, 13 Nov 2003 00:29:45 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (51 lines)
In message <[log in to unmask]>, Eben Yong
<[log in to unmask]> writes
>On Wed, 12 Nov 2003 10:54:05 -0800, Emerson, Tom
><[log in to unmask]> wrote:

>>> The other applications would not "know" that we are row-level locking


>>tells me that this is not the case.  It also suggest that "set level"
>locking it being used, perhaps by a series of "wrapper" calls that perform
>the DBLOCK/PUT-or-UPDATE/UNLOCK all at once.  As noted previously, this
>basically means that your carefully planned item (row-level) locking will
>degrade into generic set-level locking in practice.

>Yes.  It seems to me that it's best, in this scenario, to stay with the
>original plan.  Since I'm OK with running the conversion program off-hours
>and that meets the business need, then stick with that plan.

Lots of snips - intriguing problem, though.

How do you lock now, BTW? If you are not row-level (record) locking, or
set locking already you must be database locking. Seems a bit horrible
on a big, well-used database or set of bases.

If the new value is a key, and it really is a consistent key, then I
guess that instead of just updating the existing records, you could
write a new set on the new key, flip whatever says 'Use New Key' or 'Use
Old Key' to say 'Use New Key', and then delete all the Old Key records.
Then you could do it during OLTP.

*Lots* more I/O, though, and if you did have something which gave a New
Key/Old Key flip, you could just set it to 'Come Back Later' for the Key
you were flipping, and flip it in situ.....

That out-of-hours sure sounds better...

But one question intrigues me (and may either be the germ of a solution
to the do-it-during-OLTP problem, or its death knell, no matter how
fancy the locking you used was)

"During OLTP, if you were updating at the same time, and even if you
could solve the half-updated problem in some way: how would the users
know whether to use the old key or the new key for a given member?"

--
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

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

ATOM RSS1 RSS2