6.0.0-alpha12
6/12/25

[#1580] Horde SessionHandler drivers do not serialize session access
Summary Horde SessionHandler drivers do not serialize session access
Queue Horde Framework Packages
Type Bug
State Resolved
Priority 3. High
Owners Horde Developers (at)
Requester windhamg (at) email (dot) arizona (dot) edu
Created 03/18/2005 (7391 days ago)
Due
Updated 07/21/2005 (7266 days ago)
Assigned 06/23/2005 (7294 days ago)
Resolved 06/26/2005 (7291 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
07/21/2005 09:34:03 PM kevin_myer (at) iu13 (dot) org Comment #22 Reply to this comment
I just got a "Requested message not found" error, using the native 
(i.e. non-PEAR DB) MySQL session driver.  Left sidebar had updated 
with new message count in a folder, click the folder, mailbox view 
shows proper list of messages, with one unread message.  Click on the 
message, "Requested message not found".



MySQL 4.1.X, InnoDB tables.  Horde install is a fresh HEAD checkout, 
I'm the only user on this install and hitting the new database server.
07/19/2005 04:18:23 PM liamr (at) umich (dot) edu Comment #21 Reply to this comment
We tried switching to MyISAM to get around the 2GB per process memory 
limit were were encountering with InnoDB, but the application became 
unusably slow.   We had hundreds of DB connections blocked as MyISAM 
only does table level locking.



We've pretty much decided that MyISAM is not a suitable table type for 
large installations.
07/12/2005 05:06:43 PM kevin_myer (at) iu13 (dot) org Comment #20 Reply to this comment
And are you using one of the db-specific handlers, instead of the
PEAR ("sql") one? DB doesn't provide reliable transaction support
that we can use in a db-neutral way.
MySQL, however I've realized its moot anyway, because I'm not running
against a transacation-aware table type.  Time to fast track that
MySQL server upgrade...
I should qualify that and say that unless MySQL does something to 
create pseudo-transactions, we're NTST, because we are using MyISAM 
tables.  But per Marko's response to Liam's query about table types, 
it appears Marko is running with MyISAM tables with lots of concurrent 
sessions and no problems?
07/12/2005 04:58:35 PM kevin_myer (at) iu13 (dot) org Comment #19 Reply to this comment
And are you using one of the db-specific handlers, instead of the
PEAR ("sql") one? DB doesn't provide reliable transaction support
that we can use in a db-neutral way.
MySQL, however I've realized its moot anyway, because I'm not running 
against a transacation-aware table type.  Time to fast track that 
MySQL server upgrade...
07/12/2005 04:09:20 PM Chuck Hagenbuch Comment #18 Reply to this comment
And are you using one of the db-specific handlers, instead of the PEAR 
("sql") one? DB doesn't provide reliable transaction support that we 
can use in a db-neutral way.
07/12/2005 04:05:04 PM kevin_myer (at) iu13 (dot) org Comment #17 Reply to this comment
I'm starting to get bug report submissions about "Requested message 
not found", following the 3.0.5-RC1 upgrade this morning...  More 
details if I can track them down.
06/26/2005 04:28:53 AM Chuck Hagenbuch Comment #16
State ⇒ Resolved
Reply to this comment
Okay, it's all merged.
06/24/2005 10:57:26 AM kevin_myer (at) iu13 (dot) org Comment #15 Reply to this comment
It would be helpful if it was in a RC.  I'll be glad to run that in an 
early production environment but its not easy to put HEAD code through 
heavy testing when your production environment is FRAMEWORK_3.



Also, as an aside, when RC's drop, it would be helpful to have a patch 
drop along with them, so that when an official point release comes 
out, the RC patch(s) can be reversed and the official point release 
easily installed.  Or in the case of a meltdown, it would be easier to 
revert to the previous point release.
06/24/2005 08:50:17 AM Jan Schneider Comment #14 Reply to this comment
Well, the current code is obviously causing problems, so it probably 
can't get worse. I guess we'll get more feedback (or none if works 
flawlessly) if the new code is in the next RC.
06/23/2005 05:37:47 PM Chuck Hagenbuch Comment #13 Reply to this comment
If we're confident in the changes, sure. With no one testing them, I 
wasn't going to put them into a stable release.
06/23/2005 09:02:06 AM Jan Schneider Comment #12
State ⇒ Feedback
Reply to this comment
Shouldn't this be merged to 3.0.5?
05/30/2005 08:52:27 PM Jan Schneider State ⇒ Resolved
 
05/30/2005 07:24:54 PM Chuck Hagenbuch Comment #11 Reply to this comment
No feedback, so I have to assume it works now.
05/23/2005 09:09:58 PM Chuck Hagenbuch Comment #10 Reply to this comment
So, hello? Anyone going to test this?
05/18/2005 04:31:11 AM kevin_myer (at) iu13 (dot) org Comment #9 Reply to this comment
I should mention that this is using just the PHP files-based sessions 
too.  Might be a totally separate issue :/  Too late to diagnose..
05/18/2005 04:26:28 AM kevin_myer (at) iu13 (dot) org Comment #8 Reply to this comment
I'm not able to login at all anymore on my HEAD install.  Slightly 
different setup than at work, using IMP for authentication but it 
passes me through to the imp/login.php and reprompts me for my 
password again.



Here's all that's logged:



May 18 00:14:58 HORDE [notice] [imp] 192.168.1.8  [on line 31 of 
"/htdocs/horde/imp/login.php"]
05/16/2005 08:01:53 PM Chuck Hagenbuch Comment #7
State ⇒ Feedback
Reply to this comment
Can the people seeing problems related to this please try the latest 
SessionHandler commits?



http://cvs.horde.org/framework/SessionHandler/SessionHandler/



(HEAD branch, download from there if you can).



I fear that the PEAR DB driver won't work, but if you can use the 
straight mysql.php one, it should.
05/05/2005 06:13:08 PM Chuck Hagenbuch Comment #5
Priority ⇒ 3. High
Reply to this comment
Upping the priority since this seems to be the root cause of bug 1801 
and bug 1819.
03/18/2005 02:33:50 PM Chuck Hagenbuch Comment #4 Reply to this comment
We already do that.
03/18/2005 09:12:27 AM Jan Schneider Comment #3 Reply to this comment
Given that we don't write session data in the javascript files, 
wouldn't it be sufficient to open the session in javascript.php 
read-only? It's only a workaround, but a quick one.
03/18/2005 03:31:32 AM Chuck Hagenbuch Comment #2
Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
Reply to this comment
Still should be solved, and still somewhat true for javascript, but no 
longer true at all for CSS, and a bunch of javascript is loaded 
directly now.
03/18/2005 03:24:58 AM windhamg (at) email (dot) arizona (dot) edu Comment #1
Priority ⇒ 2. Medium
State ⇒ Unconfirmed
Queue ⇒ Horde Framework Packages
Summary ⇒ Horde SessionHandler drivers do not serialize session access
Type ⇒ Bug
Reply to this comment
None of the Horde Framework SessionHandler drivers address session 
serialization.  This is problematic because many Horde application PHP 
scripts (e.g., imp/mailbox.php) generate output that includes 
Javascript code that results in multiple reconnects from the browser 
(to retrieve CSS files, Javascript code libraries, etc).  If the 
original PHP script hasn't written its session state before these 
subsequent accesses occur, the session state is corrupted, due to the 
lack of serialized access.  This can be visualized as two interleaved 
threads of execution--B starting subsequent to A, and each accessing 
the same session state (x):



   A(t0)-->session_read(x)-->session_write(x)

       B(t0+delta)-->session_read(x)-->session_write(x)



In this scenario, the PHP script represented by thread A believes that 
it has committed its session state, which it has, but which is 
subsequently overwritten by the (earlier) session state contained in 
thread B.  Therefore, the output generated by A is no longer 
consistent with the session cache--resulting in "message not found" 
errors, and other oddities.  Proper serialization of session access in 
the SessionHandler drivers would alleviate this condition.


Saved Queries