AppServer Locks

[GregTomkins]

Hello Progress World

(mostly) 10.2B HPUX

We have been running AppServers for eons, and we always run them StateFree (from WebClient) or StateLess (from Web Service proxies).

We had a problem the other day where it appears (from log files) that one of our Web Services-supporting AppServers was holding a share-lock between calls to it (specifically, for several hours).

That is to say, from the user's point of view, and according to log files, the call completed normally (in 100ms or so). BUT, if you look in the Lock Table, the record was locked for far longer.

The particular call is unusual in that it does some server-side RUN ... PERSISTENT, which seems like a bit of a smoking gun, but,

(a) in testing, I can't get any combination of PERSISTENT recklessness to hold onto a record lock in this way;

(b) we have a thing in SrvrDeactivateProc which cleans up (DELETEs) all persistent procedures at the end of every call.

We are kinda new to Web Service proxies, and that's the only place we see this issue, but we have been doing Java/C# proxies as well as native WebClient AppServers for a long, long time, and AFAIK we have never seen this issue in that environment.

Any ideas?

 

[TomBascom]

Maybe a bug in your deactivate procedure caused it to fail to delete a PP that was holding the share-lock?

 

[Rob Fitzpatrick]

So, did anything change recently in prod? Code promotion? Propath change?

I would think that if this was caused by an application bug you should be able to reproduce the long-term share lock in test.

Do you know why you have the share lock in the first place, i.e. which piece of code is responsible? Is it an intentional share lock or the result of a downgrade from exclusive strength at the end of transaction scope?

 

[TheMadDBA]

When it happens again get a stack trace for the appserver process. It should show you any persistent procedures that are running.

Strong scoping (DO FOR buffer TRANS) will make those issues go away as long as the procedure actually finishes the transaction.

 

[GregTomkins]

Thanks for the feedback. Rob - you're right, I need to track that down. Tom - we have a policy against bugs, so of course it can't be that

Do you guys agree that this (an AppServer holding onto a record lock outside of the duration of a call to it) is only feasible with an uncleanedup persistent procedure? I don't see how even the most lunatic code in the actual target procedure or the Connect/Activate etc. procedures would cause this.

(BTW, I recall tamhas saying something about static classes, or maybe it was singleton?, and locks - not applicable to us, we don't use any of the ABL OO stuff).