Stevenson, Charles wrote:
> For files with sequential numbers as record IDs, it is common practice
> to use a control item (in dictionary or in a special control table) to
> get the next sequential id counter, then write back the incremented
> counter ASAP so it is available for the next process that needs to do
> the same. Some variation on this theme (probably involving a utility
> subroutine):
> READVU SEQ.ID FROM ctrl.fvar, ctrl.id, n ...
> WRITEV SEQ.ID+1 TO ctrl.fvar, ctrl.id, n
> WRITE NEW.REC TO fvar, SEQ.ID
>
> ===
> BUT:
> ===
>
> If that happens inside an explicit transaction bounded by TRANSACTION
> START and TRANSACTION COMMIT (or TRANSACTION ROLLBACK), the
> Sequential
> ID control record will not actually be written and/or
> released until all
> updates are done/ditched during commit/rollback. If the
> transaction is
> extensive and involves many updates, this could be a serious
> bottleneck.
I'm not really very fond of straight sequential IDs when the DBMS doesn't
provide inbuilt support for them,
instead I like to do something like this:
OPEN "","FILE" TO FILE_VAR THEN
SEED_HEAD = FMT(DATE(),"5'0'R"):FMT(TIME(),"5'0'R")
SEED_VAL="000"
GOT_LOCK = 0
LOOP
SEED_KEY = SEED_HEAD:SEED_VAL
READVU DUMMY FROM FILE_VAR,SEED_KEY,0 LOCKED
NULL ;* need this or READVU will block
END THEN
RELEASE FILE_VAR,SEED_KEY
END ELSE
GOT_LOCK = 1
END
UNTIL GOT_LOCK
SEED_VAL += 1
SEED_VAL = FMT(SEED_VAL,"3'0'R")
REPEAT
* now do something which uses SEED_KEY - this is yours exclusively
END
I wonder if a similar technique could be applied to your problem Chuck.
Essentially, the read of the NEXT.ID value would simply get your multiple
concurrent transactions all a start point from which they search upward
until
they find a unique value nobody else already has. Only at the completion of
their work and just before the COMMIT statement they can attempt to READU
the
NEXT.ID value and WRITE back the value they last used. If they don't
achieve a lock on this
then they simply forget it because that means someone else has a lock and is
moving the start point upwards.
Cheers,
Ken
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
