[Mediawiki-l] Ending the "1 request per browser" limit? (technical)

[Tim Starling]

On 10/08/10 03:11, Daniel Barrett wrote:
> Is there any way to disable MediaWiki's limitation of "one active
> request per browser instance"?
> 
> In our MediaWiki site, the #1 source of user confusion (by far) is
> this limit.  When a user encounters a slow wiki page and clicks the
> browser "Stop"  button, the user now cannot view any other wiki
> pages in that browser window, because the previous request hasn't
> completed. As a result, the user believes the wiki has crashed and
> files a support ticket.
> 
> Now, the user can simply close and reopen the browser to get a new
> session cookie, but in practical terms, many end-users don't know
> this. And even when they DO know it, they believe this behavior is
> a MediaWiki bug, which breeds distrust of the system, and costs us
> more time explaining why it isn't a bug.

This problem is with the design of PHP's session system. It's not
really MediaWiki's fault, although we could fix it by writing our own
MySQL-based session system and using it by default.

PHP's file-based session storage locks the session file while the
session is open. A concurrent attempt to open the same session by
MediaWiki will block until the first request is complete.

You can work around it by installing MemCached and using
$wgSessionsInMemcached = true, or by putting the session files on a
filesystem that doesn't support locking, such as NFS. Both solutions
work by simply removing all locking, so they reintroduce the bugs that
the locking in PHP was designed to prevent.

The root problem is that PHP loads the entire session into $_SESSION
(in memory), allows the script to modify it, and then stores the whole
of $_SESSION back to the file when the session is closed. If any other
changes were made to the session data while that script was running,
then those changes will be overwritten. A proper solution would have a
similar coding style to the DB update code in MediaWiki, with things
like transactions and fine-grained locking.

-- Tim Starling