Tickets :: [#8023] New Horde_Session class

6.0.0-alpha12

6/12/25

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	02/23/2009 (5953 days ago)
Due
Updated	11/21/2010 (5317 days ago)
Assigned
Resolved	11/21/2010 (5317 days ago)
Milestone	4
Patch	No

11/21/2010 07:22:19 PM	Michael Slusarz	Comment #14 State ⇒ Resolved	Reply to this comment
All code has been converted in H4.

10/12/2010 08:31:43 PM	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

10/12/2010 08:31:42 PM	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

10/09/2010 07:32:27 AM	Git Commit	Comment #11	Reply to this comment
Changes have been made in Git for this ticket: ~~Ticket #8023~~: Add transparent lzf compression to Horde_Session. Only compress arrays and objects at this time. http://git.horde.org/diff.php/framework/Core/lib/Horde/Session.php?rt=horde-git&r1=a9754245850ddedcf552aaf73195748e24d5c79b&r2=bf4c43fcee6137a1418658c79e0f6e15496d97f0 http://git.horde.org/diff.php/framework/Core/package.xml?rt=horde-git&r1=6a64863d678589d3ecbce8a97c075d2bcd84d7ae&r2=bf4c43fcee6137a1418658c79e0f6e15496d97f0

10/09/2010 07:32:25 AM	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

10/08/2010 02:29:49 AM	Chuck Hagenbuch	Comment #9 New Attachment: locking-session-code.zip	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.

10/07/2010 09:14:52 PM	Git Commit	Comment #8	Reply to this comment
Changes have been made in Git for this ticket: ~~Bug #8023~~: Initial creation of Horde_Session. Does nothing more than move code out of Horde_Registry. create mode 100644 framework/Core/lib/Horde/Session.php http://git.horde.org/diff.php/framework/Core/lib/Horde/Registry.php?rt=horde-git&r1=d6b83bfb3fd0988403c6b074a855d5c2f1342e11&r2=d2b3eb6a89d574aac60dc5150b159d1a5aadd6bc http://git.horde.org/co.php/framework/Core/lib/Horde/Session.php?rt=horde-git&r=d2b3eb6a89d574aac60dc5150b159d1a5aadd6bc http://git.horde.org/diff.php/framework/Core/package.xml?rt=horde-git&r1=d6b83bfb3fd0988403c6b074a855d5c2f1342e11&r2=d2b3eb6a89d574aac60dc5150b159d1a5aadd6bc http://git.horde.org/diff.php/horde/admin/sessions.php?rt=horde-git&r1=6fb6926b2a115f3410d0a924bc6e8eb008ee3cf9&r2=d2b3eb6a89d574aac60dc5150b159d1a5aadd6bc http://git.horde.org/diff.php/horde/bin/active_sessions?rt=horde-git&r1=406a76b3bc7dfacfaefd44dec845a6d050f7dce5&r2=d2b3eb6a89d574aac60dc5150b159d1a5aadd6bc http://git.horde.org/diff.php/horde/login.php?rt=horde-git&r1=5119c0b8e88220c9a0ac1bbdf2c75c55cd608653&r2=d2b3eb6a89d574aac60dc5150b159d1a5aadd6bc

10/07/2010 04:05:36 PM	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.

03/04/2009 11:40:21 PM	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.

02/24/2009 05:03:56 AM	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.

02/23/2009 07:28:01 PM	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.

02/23/2009 07:16:32 PM	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.

02/23/2009 06:54:02 PM	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.

02/23/2009 06:51:12 PM	Michael Slusarz	Comment #1 State ⇒ Assigned Patch ⇒ No Milestone ⇒ Assigned to Horde Developers Assigned to Michael Slusarz Queue ⇒ Horde Framework Packages Summary ⇒ New Horde_Session class Type ⇒ Enhancement Priority ⇒ 1. Low	Reply to this comment
From dev@lists: Quoting Michael M Slusarz <slusarz@horde.org>: [Show Quoted Text - 11 lines][Hide Quoted Text] 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: 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