I was surprised tonight to see that somewhere along the way Progress changed the default lock wait timeout (lkwtmo) to 10 seconds in PASOE. It is something that developers will need to know if they are migrating from "classic" appserver. The difference between the old (30 minute) default timeout and the new 10 second default is substantial.
The docs don't mention the change in the PASOE default timeout:
However I did find a reference to the change in an inconspicuous place. It is at the bottom of this KB:
"Note: Starting with OE 11.6.4 and 11.7.1, PASOE's default value for Lock Timeout (-lkwtmo) is 10 seconds."
Personally, I am happy with a relatively short timeout for waiting on a record lock. The problem is what happens when the timeout expires. Unlike most types of error conditions, this one raises a STOP condition. That makes it very troublesome to deal with. It doesn't respect a regular S.E.H. CATCH block like an ERROR condition would. Instead there are a set of very obscure rules related to the default handling of STOPs (see https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dverr%2Fdefault-handling.html%23 )
Ideally with such a short timeout, there would also be a way to have Progress raise a regular error condition that could be caught using structured error handling. I suspect there is a reason they didn't implement it this way, but it isn't obvious to me at the moment.
Yes, if the lock-wait timeout expires you will get a Stop condition, but as of 11.7 you can CATCH it by catching a Progress.Lang.LockConflict type. In 11.7, you need to use -catchStop to get this behavior. In 12 that will be the default.
We agree that this lock conflict should never have been a Stop condition in the first place. The use of Stop in the old days was more prevalent for reasons that have been lost. And we understand that it would probably be easier if it was now just another type of error, catchable with Progress.Lang.Error. But we believe that making this change could break existing applications, so we opted to make it a catchable Stop condition.
Never knew it was 30min with classic appserver. Ever since we moved from v9 to 10 + webspeed (classic appserver) and then to 11 + webspeed (classic appserver) we have been running the lock timeout at 10sec max.
Can you confirm whether webspeed applications have to deal with the STOP conditions that occur because of lock-wait timeouts? I don't have experience with webspeed, but the docs do appear to say that webspeed has a different default lock-wait timeout than other types of ABL clients (10 sec vs 30 mins).
I just found another thread that talks about the possibility of changing lock-wait-timeouts errors and making them CATCH'able.
community.progress.com/.../27280
Hopefully we'll see some changes in this area. It seems pretty disruptive for the whole ABL session to crash, simply because a record isn't available. I guess at some point it must have been unthinkable for two people to be trying to use the record at once. Either that or Progress wanted everyone to use NO-WAIT whenever locking records.
Yes, if the lock-wait timeout expires you will get a Stop condition, but as of 11.7 you can CATCH it by catching a Progress.Lang.LockConflict type. In 11.7, you need to use -catchStop to get this behavior. In 12 that will be the default.
We agree that this lock conflict should never have been a Stop condition in the first place. The use of Stop in the old days was more prevalent for reasons that have been lost. And we understand that it would probably be easier if it was now just another type of error, catchable with Progress.Lang.Error. But we believe that making this change could break existing applications, so we opted to make it a catchable Stop condition.
Laura,
I implemented the lock wait timeout way back in version 7. At that time, I made it work the same way as if you had cancelled a lock wait by pressing control-c in an interactive session where you had a message like “customer in use by bob. Press to cancel".
-gus
Ah yes. OK. But probably the GUI case should not have raised Stop either. Using Stop was much more in favor in those days - like using it when we could not find a .p on a RUN statement. The mindset has changed since then.
The timing of the STOP is also a point to consider. It is one thing to STOP a client session after 30 minutes of doing nothing. That may seem reasonable to most developers. But it is a whole different matter to STOP sessions after only ten seconds.
> On Nov 27, 2018, at 5:42 PM, dbeavon wrote:
>
> But it is a whole different matter to STOP sessions after only ten seconds.
Then change the setting of the -lkwtmo configuration parameter to a value more to your liking.=
> On Nov 27, 2018, at 5:18 PM, Laura Stern wrote:
>
> Ah yes. OK. But probably the GUI case should not have raised Stop either. Using Stop was much more in favor in those days - like using it when we could not find a .p on a RUN statement. The mindset has changed since then.
>
>
>
agreed. choices were limited in version 7.
and you could catch stop conditions