6.0.0-git
2019-05-23

[#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 (at) , slusarz (at) horde (dot) org
Requester slusarz (at) horde (dot) org
Created 2009-02-23 (3741 days ago)
Due
Updated 2010-11-21 (3105 days ago)
Assigned
Resolved 2010-11-21 (3105 days ago)
Milestone 4
Patch No

History
2010-11-21 19:22:19 Michael Slusarz Comment #14
State ⇒ Resolved
Reply to this comment
All code has been converted in H4.
2010-10-12 20:31:43 Git Commit Comment #13 Reply to this comment
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

http://git.horde.org/diff.php/framework/Core/lib/Horde/Session.php?rt=horde-git&r1=ddc248a3b4a3a362c76761312ec0b634528b3430&r2=4d2812f01520cc485dcac545c5f738b7d7b54025
2010-10-12 20:31:42 Git Commit Comment #12 Reply to this comment
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
http://git.horde.org/diff.php/framework/Core/lib/Horde/Core/Factory/Group.php?rt=horde-git&r1=c51bb9d8a341b5c12416201f6ae21168732274cd&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/framework/Core/lib/Horde/Core/Factory/Share.php?rt=horde-git&r1=c685edee620ef4d9931ef899c7f1ad162bf430af&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/framework/Core/lib/Horde/Session.php?rt=horde-git&r1=b2b8560ee168359cce8eb42f82ea1358340fa9af&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/framework/Group/lib/Horde/Group.php?rt=horde-git&r1=57a6d43c74123be9e8212734e9931032d97d8b2b&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/framework/Kolab_Session/package.xml?rt=horde-git&r1=fc2d8ef0b26a4eef81bee2bbb406fd179496fc54&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/framework/Kolab_Storage/package.xml?rt=horde-git&r1=26ba03c9bb092b872fdbd96a787ee7e10e63ea2f&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/framework/SessionObjects/lib/Horde/SessionObjects.php?rt=horde-git&r1=326e7ce0d176377f1a94f4db11d7e3a6139109af&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/framework/SessionObjects/package.xml?rt=horde-git&r1=326e7ce0d176377f1a94f4db11d7e3a6139109af&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/imp/lib/Crypt/Pgp.php?rt=horde-git&r1=00c63fa70475450522f1f98b802f50a7c6cbb5bd&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/imp/lib/Crypt/Smime.php?rt=horde-git&r1=ac924f3cbf088390bf3dcef34f95c051b2a92c7b&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/imp/lib/Injector/Factory/Compose.php?rt=horde-git&r1=00c63fa70475450522f1f98b802f50a7c6cbb5bd&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/imp/lib/Prefs/Ui.php?rt=horde-git&r1=00c63fa70475450522f1f98b802f50a7c6cbb5bd&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
http://git.horde.org/diff.php/ingo/lib/Storage.php?rt=horde-git&r1=326e7ce0d176377f1a94f4db11d7e3a6139109af&r2=ddc248a3b4a3a362c76761312ec0b634528b3430
2010-10-09 07:32:25 Git Commit Comment #10 Reply to this comment
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:
$_SESSION['app']['foo']

Now looks like:
$GLOBALS['session']['app:foo']

http://git.horde.org/diff.php/framework/Core/lib/Horde/Session.php?rt=horde-git&r1=d2b3eb6a89d574aac60dc5150b159d1a5aadd6bc&r2=a9754245850ddedcf552aaf73195748e24d5c79b
2010-10-08 02:29:49 Chuck Hagenbuch Comment #9
New Attachment: locking-session-code.zip Download
Reply to this comment
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.
2010-10-07 16:05:36 Michael Slusarz Comment #7
Priority ⇒ 3. High
Milestone ⇒ 4
Reply to this comment
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 
collected.
2009-03-04 23:40:21 Michael Slusarz Comment #6 Reply to this comment
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.
2009-02-24 05:03:56 Chuck Hagenbuch Comment #5 Reply to this comment
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.
2009-02-23 19:28:01 Michael Slusarz Comment #4 Reply to this comment
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.
2009-02-23 19:16:32 Chuck Hagenbuch Comment #3 Reply to this comment
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.
2009-02-23 18:54:02 Michael Slusarz Comment #2 Reply to this comment
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.
2009-02-23 18:51:12 Michael Slusarz Comment #1
Type ⇒ Enhancement
State ⇒ Assigned
Priority ⇒ 1. Low
Summary ⇒ New Horde_Session class
Queue ⇒ Horde Framework Packages
Assigned to Michael Slusarz
Assigned to Horde DevelopersHorde Developers
Milestone ⇒
Patch ⇒ No
Reply to this comment
From dev@lists:



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

[Show Quoted Text - 11 lines]
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:



http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/



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



-chuck


Saved Queries