[Tickets #8023] Re: New Horde_Session class

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/8023
------------------------------------------------------------------------------
  Ticket             | 8023
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | New Horde_Session class
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Enhancement
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Horde Developers, Michael Slusarz
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2009-02-23 14:28) wrote:

> Any time you try to do something in a second tab while a mailbox is
> being filtered or emptied, for example. Or when the current sidebar
> ajax reloads while another page is loading. And I expect all of this
> to get more common with rich apps where ajax requests can fire from
> different parts of the page.

These are performance issues rather than race conditions though.  I  
can live with performance issues if using multiple different tabs.   
The article linked to in this article mostly seems concerned with race  
conditions.  Since we do locking in our sessionhandlers, it does not  
pertain to us.

> As long as we have longer-running requests and/or large items in the
> session, I think it's a good idea to be able to separate them. If we
> use the session_write_close/session_open trick and stop storing
> things like MIME objects in the session, then I can let it go.

We don't store MIME objects in the session (not since the MIME  
rewrite).  In fact, the major culprit size-wise is registry data  
(almost 35% of the session size) and cached prefs data.  I've been  
thinking about ways to remove the registry data for months now, since  
95% of the data in there is never used by the application in any given  
session.  In terms of improving session size, this is the place to  
attack.  I'll file another ticket for this issue.