03-22-2023, 08:36 PM
(This post was last modified: 03-22-2023, 09:24 PM by Alexandre Machado.)
Hi there,
This exception does/should not cause any side effects on the server side other than possibly showing an error to that specific user.
The "Session is already locked" event happens when the following situation occurs:
1) Session X receives a request (let's call it Request A) and starts processing it. IW "locks" this session, i.e. the session is flagged as "in use" so it can't be destroyed/removed/terminated. This flag will be cleaned when the response is sent back to the browser
2) During that time, that specific Session X can't respond to other requests.
3) If during that time IW receives a new request targeting session X, Request B, it will hold this request and put it in a wait state, up to SessionOptions.LockSessionTimeout milliseconds. If the request A is responded before the SessionOptions.LockSessionTimeout expires, Request B will be processed in sequence and will also be responded. However, if request A takes a long time to respond (imagine a big report being generated), then the Request B wait state will "timeout" and this error will be responded back to the browser (which actually means: the server is busy processing your prior request now and can't process a new request at the moment)
Due to the nature of the callback (an async enter event) I'd suggest that you inspect your code and look for reasons for this to happen. Possibly the user is triggering something that will take a long time and moving the cursor to this input field (CODIGOARTIGO) which has the event attached. In that case, I suggest that you lock the screen while waiting for this action to complete before letting the user move to this field.
Regarding this service "crashing", is there any other exceptions happening? This exception here, as I said, is normal, expected and treated inside IW and won't cause any issues on the server side, so it shouldn't be causing any service crash.
This exception does/should not cause any side effects on the server side other than possibly showing an error to that specific user.
The "Session is already locked" event happens when the following situation occurs:
1) Session X receives a request (let's call it Request A) and starts processing it. IW "locks" this session, i.e. the session is flagged as "in use" so it can't be destroyed/removed/terminated. This flag will be cleaned when the response is sent back to the browser
2) During that time, that specific Session X can't respond to other requests.
3) If during that time IW receives a new request targeting session X, Request B, it will hold this request and put it in a wait state, up to SessionOptions.LockSessionTimeout milliseconds. If the request A is responded before the SessionOptions.LockSessionTimeout expires, Request B will be processed in sequence and will also be responded. However, if request A takes a long time to respond (imagine a big report being generated), then the Request B wait state will "timeout" and this error will be responded back to the browser (which actually means: the server is busy processing your prior request now and can't process a new request at the moment)
Due to the nature of the callback (an async enter event) I'd suggest that you inspect your code and look for reasons for this to happen. Possibly the user is triggering something that will take a long time and moving the cursor to this input field (CODIGOARTIGO) which has the event attached. In that case, I suggest that you lock the screen while waiting for this action to complete before letting the user move to this field.
Regarding this service "crashing", is there any other exceptions happening? This exception here, as I said, is normal, expected and treated inside IW and won't cause any issues on the server side, so it shouldn't be causing any service crash.