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 |
(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.
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.
PEAR ("sql") one? DB doesn't provide reliable transaction support
that we can use in a db-neutral way.
against a transacation-aware table type. Time to fast track that
MySQL server upgrade...
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?
PEAR ("sql") one? DB doesn't provide reliable transaction support
that we can use in a db-neutral way.
against a transacation-aware table type. Time to fast track that
MySQL server upgrade...
("sql") one? DB doesn't provide reliable transaction support that we
can use in a db-neutral way.
not found", following the 3.0.5-RC1 upgrade this morning... More
details if I can track them down.
State ⇒ Resolved
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.
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.
wasn't going to put them into a stable release.
State ⇒ Feedback
too. Might be a totally separate issue :/ Too late to diagnose..
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"]
State ⇒ Feedback
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.
http://www.issociate.de/board/post/184369/warning_&_question_about_mysql_sessions_&_concurrency.html
Priority ⇒ 3. High
bug 1801and
bug 1819.wouldn't it be sufficient to open the session in javascript.php
read-only? It's only a workaround, but a quick one.
Assigned to
State ⇒ Assigned
longer true at all for CSS, and a bunch of javascript is loaded
directly now.
Priority ⇒ 2. Medium
State ⇒ Unconfirmed
Queue ⇒ Horde Framework Packages
Summary ⇒ Horde SessionHandler drivers do not serialize session access
Type ⇒ Bug
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.