Posts: 95
Threads: 20
Joined: Mar 2018
Reputation:
1
Can someone please advise what ServerControler.LockSessionTimeout is and where / how it is used.
Also is the value expressed in minutes, seconds, milliseconds:
TIA
Posts: 2,302
Threads: 204
Joined: Mar 2018
Reputation:
87
Location: Auckland, New Zealand
08-27-2018, 10:02 PM
Default value is 30000 milliseconds
it represents the time IW will wait before rejecting a request for a locked session. This shouldn't happen in normal circumstances, but it is possible that the same session receives 2 requests which require session locking. So, imagine this scenario:
- Request 1 locks session "A"
- Session "A" starts processing request 1 and generating a new response
- Request 2 is received also requiring session "A"
- Session "A" can't be locked again, so request 2 is put on hold until request 1 is completed
- The wait time can be up to "LockSessionTimeout" milliseconds, i.e. after 30000 milliseconds, if Request 1 is not yet completed, IW server will respond to Request 2 with an error, so it will know that the server can't respond to that request at that time
Posts: 95
Threads: 20
Joined: Mar 2018
Reputation:
1
Thanks Alexandre.
What is the error that is returned?
TIA
Posts: 2,302
Threads: 204
Joined: Mar 2018
Reputation:
87
Location: Auckland, New Zealand
Hi,
I suggest you turn on dev tools network tab in your browser and check all requests going to your server. A particular session can only process one request at a time. Please notice that not all requests require session locking (everything which is static shouldn't require, like images, CSS files, JavaScript files - both internal to IW and external) unless there is a problem in the method call. Everything which calls an event handler (e.g. OnAsyncClick, OnChange, etc) requires session locking.
So if RequestA goes to the server and requires session locking (e.g. it triggers OnAsyncClick event), the session will be locked for the duration of RequestA processing. If during that time your some JavaScript code posts another request, say RequestB, which also requires locking, there might be problems if RequestA takes too long. Typical calls are processed very quickly and this might never be a problem. But let's say that RequestA generates a huge report on the server side which takes more than the LockSessionTimout time, then it might fail.
You have 2 options: Increate LockSessionTimeout time or (the preferred) understand and possibly avoid why your browser is posting 2 requests in parallel to your application. This shouldn't happen under normal circumstances (except, as I mentioned, request for static files like CSS and JS).