Tickets :: Comment on [#13231] Hashtable session handler doesn't unlock on session close

* Your Email Address
* Spam protection	Enter the letters below: .__..___..___.__ . [__] _/ [__ [__)\| \| \|./__.\| \| \|___
Comment	>> If Kronolith for some >> reason sends 15 listEvents requests in a row, it is a reasonable >> assumption that the 15th is the least important request. It should >> not, by virtue of random luck, suddenly jump to 2nd in the queue. > > For the sake of completeness, the earlier requests are the requests > that are (supposed) to take the least amount of time to complete. > I.e., internal calendars. The later requests are those that may take > a longer time, such as remote calendars. > >> ... especially since I am not convinced that the use-case here is >> what needs enhancement, not the session storage. > > Your earlier comment about it working that way "because that's the > way the javascript code was written." isn't correct. It was written > that way because we don't want the user waiting for EVERY SINGLE > calendar to be loaded into memory before we send anything back to the > client and update the UI. This would create an unnecessary wait time > for users that have, e.g., any slowly responding remote calendars. > > IMO, it doesn't make any sense to force this extra wait time on the > user because one of the (not even recommended) session handlers > doesn't work satisfactorily.
Attachment
Watch this ticket