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:
Eben Yong <[log in to unmask]>
Reply To:
Eben Yong <[log in to unmask]>
Date:
Thu, 13 Nov 2003 10:24:38 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (46 lines)
On Thu, 13 Nov 2003 00:29:45 +0000, Roy Brown
<[log in to unmask]> wrote:

>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.

Currently, our existing custom apps do not "mess" with the vendor DB in a
way that requires explicit locking.  We have many QUICK screens that
handle the required locking mechanisms without explicit programmer
knowledge, per se, of locking requirements.

>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?"

This boils down to training.  We will be creating a cross-reference table
that users can use to look up the "old" key and find the "new" key.  Then,
they would use the "new" key to look up the member's information.

Another question, however.  If DBXBEGIN is called and the program crashes
without DBXUNDO or DBXEND being called, what is the impact on the
database?  Does it automatically result in a rollback, a commit, or
something halfway in-between?

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

ATOM RSS1 RSS2