Hey thanks for replying, I suspect its because it was coded for an older version of Progress where the default was "no_lock" if no locking parameters were specified. Do you think this a reasonable assumption?? . I have added a screen shot from promon R&D , please note the db has been up for only 73 hours but has over 9.5 billion share locks.Any Share Lock is just wrong...
I can't think of a single version of Progress that ever had NO-LOCK as the default... going back to the 1980s.
There is a startup parameter to set the default to NO-LOCK... but use great care in turning it on for compiles because it can easily break code.
Those numbers are a crime against humanity.
Hi Tom, I wasn't blaming older versions of Progress, just trying to rationalise where all these locks could be coming from. I agree its totally code related but our application developer is unmoved. I don't develop databases just general IT guy trying to fix customer locking issues.I think this thread could be summed up with my favorite tuning advice "fix your crappy code!"
Don't go blaming it on older versions of Progress. There has never been a good excuse for writing crappy code like this. Progress has always had all of the pieces needed to write good clean locking logic. The problem has been that all too many applications, including some very famous ones, were written by people who never gave a thought to multi-user usage and who never tested such things. And then their horrible designs were copied by people with even more myopic views.
yep sorry typoThe default has always been SHARE-LOCK... there is a -NL option you can use that changes the compile time default to NO-LOCK. If a method is specified it always uses that method regardless of the startup option.
-n is the number of users.
10.2b,Can't see from a quick scan: what version of Progress are you currently running?
This useful feature was added in 10.1C.With later versions of Progress (11+ IIRC) you can use client statement caching