Why should the locks and unlocks enclose the transaction markers?

Jim




> Date:          Fri, 16 Oct 1998 16:02:04 -0400
> Reply-to:      John Zoltak <[log in to unmask]>
> From:          John Zoltak <[log in to unmask]>
> Subject:       Re: Dynamic transactions spanning multiple databases i n Image
> To:            [log in to unmask]

> Hi Tony,
>
> 1. Sequence matters - DBLOCK then DBXBEGIN then DBXEND or DBXUNDO and
> then DBUNLOCK.
>
> 2. I use unconditional locks most of the time. Either way the user is
> going to have to wait. You may as well get into the queue now instead of
> polling.
>
> 3. To rollback, just DBXUNDO, DBUNLOCK.
>
> As a note, I use this scheme to do shop order part issues which involves
> many transactions. When I find later that some part cannot be issued, I
> can undo the whole transaction. It works very nice.
>
> John Zoltak
> North American Mfg Co
>
> > -----Original Message-----
> > From: Tony Furnivall [SMTP:[log in to unmask]]
> > Sent: Friday, October 16, 1998 3:46 PM
> > To:   [log in to unmask]
> > Subject:      [HP3000-L] Dynamic transactions spanning multiple
> > databases in Image
> >
> > Hi there, Image gurus.
> >
> > I have a client who wants to work with dynamic transactions
> > (DBXBegin/DBXEnd/DBXUndo) that span multiple databases. (Just
> > naturally
> > masochistic, I guess!) We have discussed the strategy for sequencing
> > calls,
> > and I said I would run our tentative decisions by the list.
> >
> > We have a variable number of databases, which will be accessed via a
> > table
> > of BaseIDs. The table allows us to indicate whether or not a
> > particular
> > BaseId is participating in the gruesome activity.
> >
> > All bases are actively logging, independently, to individual log
> > files.
> > There could be between 3 and 6 databases participating at any one
> > time.
> >
> > For each BaseID we have a published lock sequence strategy for locks
> > at the
> > set level, although we expect to be able to get by with predicate
> > level
> > locking for the most part.
> >
> > We plan (tentatively) on using the following sequence of operations,
> > where
> > the [] surrounding the name of an intrinsic imply that that operation
> > is
> > done on each BaseId in the table, as needed, in sequence:
> >
> >      [DBXBEGIN]
> >      [DBLOCK - (predicate level lock, varying by BaseId) ]
> >      [DBMashTheDataUsing DBPUT/DBUPDATE/DBDELETE]
> >      [DBUNLOCK]
> >      [DBXEND]
> >
> > I have some questions to satisfy my own curiosity:
> >
> > 1.  Does the relative sequence of [DBXBEGIN]/[DBLOCK] matter? The
> > manual
> > implies that it doe NOT, but it would be good to hear from somebody
> > who has
> > engaged in this sort of behaviour!
> >
> > 2.  We are thinking of using conditional locking, just in case someone
> > somewhere has different ideas about sequences. Any strong thoughts
> > either way?
> >
> > 3.  In the event that we roll back one of these mega transactions,
> > will a
> > simple sequence of:
> >
> >      [DBUNLOCK]
> >      [DBXUNDO]
> >  be enough, or should we be 'clever' in situations like this?
> >
> > As usual, any help and comments will be appreciated.
> >
> > Tony
>

Jim Kramer /Lund Performance Solutions
Director of Research and Development
phone: (541) 926-3800  fax:   (541) 926-7723
email: [log in to unmask]    home:  [log in to unmask]
http://www.lund.com