Atozed Forums

Full Version: LockSessionTimeout
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Can someone please advise what ServerControler.LockSessionTimeout is and where / how it is used.

Also is the value expressed in minutes, seconds, milliseconds:

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
Thanks Alexandre.

What is the error that is returned?

This is the standard error message:

Please notice that it can also result in an Async request.
(09-04-2018, 08:50 AM)Alexandre Machado Wrote: [ -> ]This is the standard error message:

Please notice that it can also result in an Async request.

ok! That give me something to work with...

The issue I am experiencing with one of my users is that sometimes the CGD grid has not loaded when the user clicks an edit button and the "session already locked" occurs.

I have not yet found a fool proof method for locking the page during this process. I have a page lock with on the component that triggers the retrieval of the data but the page is released before the grid data loading  has completed.

The grid data load does sometimes take a while...

Thanks again

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).