[Tickets #13231] Re: Hashtable session handler doesn't unlock on session close
noreply at bugs.horde.org
noreply at bugs.horde.org
Thu May 29 17:08:21 UTC 2014
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: http://bugs.horde.org/ticket/13231
------------------------------------------------------------------------------
Ticket | 13231
Updated By | Michael Rubinsky <mrubinsk at horde.org>
Summary | Hashtable session handler doesn't unlock on session
| close
Queue | Horde Framework Packages
Version | Git master
Type | Bug
State | Feedback
Priority | 1. Low
Milestone |
Patch |
Owners |
------------------------------------------------------------------------------
Michael Rubinsky <mrubinsk at horde.org> (2014-05-29 17:08) wrote:
> 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.
More information about the bugs
mailing list