Hello, Thanks for your very good suggests. I put some comment on each part of your reply.
My solution is probably : - isolate the TRANSACTION BEGIN/COMMIT/ABORT on a TransactionSubr (already done). - allocate a TransactionName to the "transaction" when BEGIN (stored into a namedcomon) - into ReaduSubr, associate the locks_id (filename/key) with the "Active" TransactionName -- then if a defined limit is reach the ReaduSubr can escalate to FILELOCK - into the TransactionSubr when COMMIT/ABORT, free the TransactionName/locks_id table. Looks like maintain a "application level locks table". I'll probably do it like this because it is a "global" solution with no dependencies (OS,OE,...) only BASIC . With kind regards. Manu Ps : I put some comment on each part of your reply. > -----Message d'origine----- > De : [email protected] [mailto:u2-users- > [email protected]] De la part de Charles Stevenson > Envoyé : lundi 7 septembre 2009 17:10 > À : [email protected] > Objet : Re: [U2] UV:basic readu lock promote to filelock when locktable is > full !! > > 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. > [manu:] Yes, seems more quick than a EXECUTE 'LIST.READU ':@USERNO CAPTURING CAPT but heavy to check "How many locks have I". ------------------------------------------------------- > 2. If I read your question correctly, your readus are isolated to a > particular subroutine or set of routines. [manu:] Yes > 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.) [Manu:] yes, that the IBM approach, yes, and my choice to build a BASIC locks table. ------------------------------------------------------- > 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. [manu:] my first "solution" yes ------------------------------------------------------- > > 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. [manu:] no trouble at this level, keys are numeric and fully distributed into locks table. ------------------------------------------------------- > 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? [manu:] yes, Universe TRANSACTION Processing START/COMMIT/ABORT > > > Chuck > _______________________________________________ > U2-Users mailing list > [email protected] > http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
