6.0.0-beta1
▾
Tasks
New Task
Search
Photos
Wiki
▾
Tickets
New Ticket
Search
dev.horde.org
Toggle Alerts Log
Help
8/11/25
H
istory
A
ttachments
C
omment
W
atch
Download
Comment on [#7712] Memcache Session handler, shouldn't unlock if no data in memcache
*
Your Email Address
*
Spam protection
Enter the letters below:
.___.___.__ .___. . [__ [__ [ __[__ | | [___[___[_./[___|__|
Comment
> From looking through the current memcache session handler in CVS HEAD > (and the FW 3 Branch), it seems that there is a locking issue that > can occur on new sessions. > > > > In the code you > > 1) create a lock > > 2) try and read the data from memcache. (in case of a new session > this will be nothing) > > 3) if there is no data then you release the lock > > .... Later on page close > > 1) write the data (creating a new session) > > 2) release lock if set. > > > > Now, the issue is if two requests happen to occur around the same > time when there is no session data (ie.. expired) then there is a > high probability that they will overwrite each other. > > > > Example > > Req 1> New Request > > Req 1> Fetch Session (no data, expired, release lock) > > Req 2> New Request > > Req 2> Fetch Session (No data, expired, release lock) > > Req 2> Processing > > Req 2> Store Session > > Req 2> End Request > > Req 1> Store Session > > Req 1> End Request > > > > Because there is no lock, Req 1 overwrites Req 2s data (and Req 2 is > allowed to actually run even though it should have waited for Req 1). > > > > The worse case is this, (ie login scenario) > > R 1> New Request > > R 1> Fetch Session (no data, expired, release lock) > > R 1> Login attempt > > R 2> Nww Request > > R 2> Fetch Session (no data, expired, release lock) > > R 1> Process Login > > R 2> Do something else > > R 1> Store Session > > R 1> End Request > > R 2> Store Session (Overwriting Requests 1's login session) > > R 2> End Request > > > > This results in the users session being overwritten by another > request that user pushed through and thus, they are not logged in. > > > > The solution would be to *NOT* release the lock if there is no > session, because we ARE going to be writing at the end of the request.
Attachment
Watch this ticket
N
ew Ticket
M
y Tickets
S
earch
Q
uery Builder
R
eports
Saved Queries
Open Bugs
Bugs waiting for Feedback
Open Bugs in Releases
Open Enhancements
Enhancements waiting for Feedback
Bugs with Patches
Enhancements with Patches
Release Showstoppers
Stalled Tickets
New Tickets
Horde 5 Showstoppers