Lock table -L settings

[UKStratfordMike]

Site: New Dell Server 16 procs, SAN, Windows and Vmware. Progress V9.1D (sorry!) with 4 dedicated procs, 4Gb physical memory (6Gb virtual)
Software house app running core business – c. 100 on line users. Also have up to 5 users who can fire bulk data/updates into app (using vendor programs) which will necessitate locking.


Symptoms:
1) Frequent occurrences of -L exceeded. Big frustrations for users, disruption to customer tel calls etc

Supplier input

1) Our Progress expert (who I believe over and above anyone) tells us 'The –L parameter is currently set to 18,000. The cost of increasing the size of the Lock Table is a small amount of memory. We recommend increasing the size to 100,000.'
2) App vendor says 'it might slow it down'. Eventually agreed to raise -L to 25k. Intransigent any more than 25k.

Where now?

1) Without divulging IPR, is it possible to have an overview of how Progress checks lock table. More for personal understanding, but will enable us to sanity check validity of App vendor's view

2) Opinion from Progress – let's get the supplier's comments

 

[Casper]

When a user logs out, the lock table is checked for any pending locks for that user. The bigger the lock table the longer takes for the user to log out. But I was never able to really measure this.

Having to crash your sessin or the database (is also a possibilty) because of a -L value set too low is IMO more time consuming then any potential slowing down of the application because of a bigger Lock table. In memory terms it doesn cost much memory as well. (in 10.2A 64 bytes per entry)
I would go for setting -L to 100000.
There is a great change the Lock table isn't big enough because of the handling of transactions within the apllication of the vendor itself.
There are many programmers/analist who confuse a Progress transaction with a business transaction. The most efficient way of dealing with transaction is too have 1 transaction per ~100 changed recrods.
This way the transaction keeps small and there would possibly be no need to increase the -L.

In summary I think the best way of dealing with your particular problem is to increase -L to 100000 (or 102400 ;-)).

Regards,

Casper.

 

[TomBascom]

Progress won't comment here (they don't hang out here) and would never say anything that a supplier might be offended by.

Your "supplier" has no credibility in any case. They are, after all, supplying you with 9.1D; an ancient, obsolete and unsupported release of Progress.

And unless you have been making custom code changes they are responsible for the crappy code that requires so many locks in the first place.

Increasing -L is easy and fairly painless. It won't cause overall application slowness. What it will do is allow crappy code to execute and, if left that way, it will encourage the responsible programmers to create more. You really ought to track down the source of the need for so many locks and fix it. But I wouldn't hold my breath expecting a supplier as savvy as the one that you have to help.

 

[UKStratfordMike]

Thanks guys
I was of same view - poor code and increase to 100k to get out of problem short term. I'm an out of retirement oldie from V7 days so my street cred this supplier lower than a snakes belly. Great to get conf that I'm not losing the plot!

Casper - IMO?