HP3000-L Archives

October 1998, Week 3

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:
John Zoltak <[log in to unmask]>
Reply To:
John Zoltak <[log in to unmask]>
Date:
Fri, 16 Oct 1998 16:02:04 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (87 lines)
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

ATOM RSS1 RSS2