Manu,
1. As to your specific question about figuring out how many locks your
process or transaction owns, I don't know a quick function for that,
but there is a little known "INTERNAL" keyword for LIST.READU (&
PORT.STATUS).
E.g.,
EXECUTE "LIST.READU USER nnn INTERNAL" CAPTURING XYZ
then parse XYZ.
Sounds expensive to do frequently, but infrequent is reasonable.
2. If I read your question correctly, your readus are isolated to a
particular subroutine or set of routines.
If so, how about defining labeled common where you, yourself, can
increment/reset a lock counter and check it if it is so big that you
need to promote from record- to filelock? (I'm not crazy about this.
It moves what is properly dbms-level tuning deep down into the
application layer, requiring future tweaks each time the platform changes.)
3. More generally, it seems like the simplest solution would be to just
increase the size of the lock table.
It means taking some memory out of general service & reserving it for
these rare large transactions, but memory is relatively cheap. That
is, it's cheap unless you're already at the upper edge of hardware
capability at the moment.
4. I assume you have a fairly even distribution of locks over the whole
lock table? If it is lumpy, one part can be full, and the solution may
be to define ids or files a little differently. But let's talk about
that solution only if that is really the problem.
5. Just to be clear, when you say "TRANSACTION", you mean a formal UV
transaction using TRANSACTION START/COMMIT/ABORT,etc. syntax, right? Or
do you mean it informally, a logical transaction at the application layer?
Chuck
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
