[#8023] New Horde_Session class
Summary New Horde_Session class
Queue Horde Framework Packages
Queue Version Git master
Type Enhancement
State Resolved
Priority 3. High
Owners Horde Developers, slusarz@horde.org
Requester slusarz@horde.org
Created 2009-02-23 (4621 days ago)
Updated 2010-11-21 (3985 days ago)
Resolved 2010-11-21 (3985 days ago)
Milestone 4
Patch No

Michael Slusarz <slusarz@horde.org> 2009-02-23 18:51:12
From dev@lists:

Quoting Michael M Slusarz <slusarz@horde.org>:

> Horde_Cache does not work in the situation where we absolutely 100%

> need to guarantee that the data will be available.  For example, with

> the pgp/smime reload stuff, it is simply too much of a hassle to carry

> around the reload URL data from page to page.  It is much easier (and

> more secure) to store the URL in a session variable instead.

> Obviously, we could directly store this data in a temporary session

> variable, but that feels hackish at best.


> This could never be offloaded to Horde_Cache because, e.g. with

> memcache, there is no way to guarantee that any piece of data will

> persist.

Got it. Horde_SessionObjects was originally designed to be a queue

that wouldn't grow beyond a certain point, so it shouldn't be the

answer here either, really. :)

> It might be useful to refactor Horde code to call an API in order to

> interact with all session data.  Would allow us to do stuff like

> transparent compression of larger pieces of session data.

Compression is probably the best argument I've heard for having an

abstraction layer over sessions. The other reason is to separate data

into different buckets, so that we don't have a single, locking blob

of data. I've been interested in doing this for a while, inspired by

this article:


What do you think of replacing sessionobjects with something more like that?


Michael Slusarz <slusarz@horde.org> 2009-02-23 18:54:02
FWIW, I am not really excited about the idea of "per-variable" 
locking.  That's a boatload of overhead for a dubious gain.  I can't 
think of a place in Horde where we run into race conditions right now.

Chuck Hagenbuch <chuck@horde.org> 2009-02-23 19:16:32
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.

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.

Michael Slusarz <slusarz@horde.org> 2009-02-23 19:28:01
> 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.

Chuck Hagenbuch <chuck@horde.org> 2009-02-24 05:03:56
Yes, I agree about performance vs. race conditions. I'm focusing on 
performance here. If you have another way in mind to not lock out a 
user while a long-running page is processing, that's fine, but I want 
Horde 4 to have some easy way to take care of that problem.

Michael Slusarz <slusarz@horde.org> 2009-03-04 23:40:21
Another bonus of this approach: allows us to determine if session data 
has changed without needing to do serialize->md5 twice a page load on 
the session data.

Michael Slusarz <slusarz@horde.org> 2010-10-07 16:05:36
Another feature: remove SessionObjects code and incorporate 
functionality here.  Provides quick/easy way for apps to store data 
that needs to persist over a page load but can eventually be garbage 

Git Commit <commits@lists.horde.org> 2010-10-07 21:14:52

Chuck Hagenbuch <chuck@horde.org> 2010-10-08 02:29:49
Cool. FWIW I'd still love to see some sort of per-scope locking 
implemented here - definitely not per-variable. I'm attaching some 
code that I think was from the original article I referenced. Another 
way to go here would be some sort of HTML 5 storage, or an abstraction 
around that, to keep the data on the client.

Git Commit <commits@lists.horde.org> 2010-10-09 07:32:25
Changes have been made in Git for this ticket:

Ticket #8023: Add ArrayAccess implementation to Horde_Session.
This is the new API for accessing session variables.  What previously
looked like:

Now looks like:


Git Commit <commits@lists.horde.org> 2010-10-09 07:32:27

Git Commit <commits@lists.horde.org> 2010-10-12 20:31:42
Changes have been made in Git for this ticket:

Remove horde/SessionObjects and replace with Horde_Session use
NOTE: Did not change Kolab_Session usage because I have little/no idea
what is going on in there (injecting may be good for some things, but
things, but it does make it MUCH more difficult to try and track the code.
Granted, some of this may be simply that I am not familiar with the
Kolab code, however...)

Ticket #8023

  delete mode 100644 framework/SessionObjects/lib/Horde/SessionObjects.php
  delete mode 100644 framework/SessionObjects/package.xml

Git Commit <commits@lists.horde.org> 2010-10-12 20:31:43
Changes have been made in Git for this ticket:

Allow ability to search session subkeys.
We store values with key & subkey together to save on storage/serialization
costs. To retrieve array like output, simply need to call
$session['app:name/'] - returns an array with subkeys as keys and session
values as values.

Ticket #8023


Michael Slusarz <slusarz@horde.org> 2010-11-21 19:22:19
All code has been converted in H4.