Jim,

After re-reading the image manual I found something new to me. The
DBXBEGIN can occur before or after the DBLOCK, but the DBUNLOCK must
occur after the DBXEND/DBXUNDO as per image manual page 7-11. When I
started using dynamic transactions I found that the DBUNLOCK had to be
after the transaction so I just figured that the DBLOCK had to be before
the start of the transaction.

John Zoltak
North American Mfg Co

> -----Original Message-----
> From: Jim Kramer [SMTP:[log in to unmask]]
> Sent: Monday, October 19, 1998 12:59 PM
> To:   [log in to unmask]; John Zoltak
> Subject:      Re: Dynamic transactions spanning multiple databases i n
> Image
>
> 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