Jim writes:
        I'm locking at the entry level (predicate lock) so I
        can't lock until I know what I need to lock, hence the
        locks inside the DBX block.  That is, some locks in
        are based on variable data not known until some other
        record is retrieved (think "serial number").

Jim,  one way around this (you may have already thought of this) is to pre-read all of the keys that you'll need for a given logical transaction.  Store the relative address of the entries as well as the keys per entry to lock on (you'll also want to store some unique identifier (the total set buffer if required) for your set entries...more on that later).  Once you've assembled all of the keys you'll need for the transaction, you can issue your locks (with the keys you stored), then do mode 4 reads (using the relative record address values you stored).  Now, about those unique data you stored per set entry:  you'll need these to ensure that the entries you've just read using the relative keys are the same entries you read previously...often time, the key values of the entries are enough to satisfy this requirement (although rare, it is possible for someone to delete one of your entries, and then a subsequent put occupies the address you're going to read (or the address is simply empty)).

While this is, no doubt, a more complex solution, it can get you where you need to go (everything locked prior to the DBXBEGIN), and since you've taken the time to use the DBX process calls, then it's assumed you have a significant reason to do so, and you want to succeed as best you can.


HTH,


Ray Shahan

> -----Original Message-----
> From: HP-3000 Systems Discussion [SMTP:[log in to unmask]] On Behalf Of Jim Phillips
> Sent: Monday, August 23, 2004 7:05 PM
> To:   [log in to unmask]
> Subject:           Re: [HP3000-L] DBXBEGIN/END, Locking, and Committment
> 
> --- Brian Donaldson <[log in to unmask]> wrote:
> 
> > I use these DBX procedures all the time and have no
> > trouble with
> > them at all.
> 
> I was semi-fearing that! :-)
> 
> > The logic I use all the time is to DBLOCK all the
> > necessary sets first,
> > then call DBXBEGIN. (Program needs MR for this).
> 
> 
> > With the latest versions of TurboIMAGE the deadlock
> > detect flag is usually
> > ON and so a deadly embrace is rare these days.
> > Instead of a deadly embrace
> > TurboIMAGE will return a 26 error code on the 2nd or
> > nth call to DBLOCK.
> >
> > After all the updating (DBPUT, DBDELETE, DBUPDATE)
> > has completed I do
> > DBXEND (or DBXUNDO if an error occurred). After the
> > DBXEND has completed
> > I call DBUNLOCK.
> >
> > I ALWAYS, ALWAYS, ALWAYS do *error checking* after
> > each and every TurboIMAGE
> > call and that includes DBUNLOCK.
> 
> Good idea.  I am doing the same.  There are error
> checks after every call and none of them has failed,
> as far as I can tell.
> 
> > The only reason your transactions posting is flakey
> > on occasion is that
> > the DBXEND may have failed (?), or the DBUNLOCK has
> > failed (?)
> 
> Actually, the DBXEND failing should not prevent the
> DBUNLOCK from releasing locks, should it?
> 
> > To debug this problem you will probably have to put
> > displays in your
> > source code after each Image call to see what the
> > error codes are after
> > DBLOCK, DBXBEGIN, DBXEND and DBUNLOCK etc...
> >
> > I suspect the problem is your app
> 
> Hey, I resemble that remark!
> 
> Thanks for the second look, Brian.  I think maybe too
> many margaritas might have clouded my vision!  Guess
> it's back to the coding board.
> 
> Jim Phillips In El Paso.....
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail
> 
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> 
> ========================================================================> 
> This e-mail message has been scanned for Viruses and Content and cleared 
> by School Specialty's email filtering solution.

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