You need to log in before you can comment on or make changes to this bug.
I have a situation where Chameleon is used in a frameset, and scripts in the other frames also access session data from the Chameleon application. I found out that parallel read/write operations in the session directory cause strange results. A workaround is to use the attached patch for chameleon/htdocs/common/session/session.php, which enables session locking when the global variable $GLOBALS['bSessionLock'] is set to true. Just apply the path and add $GLOBALS['bSessionLock'] = true at the top of your scripts. The modified session.php uses the already implemented session locking feature, which is used only on WIN32 platforms by original design. -------------------------------------------- patch is against CVS version from 2004-10-04 -------------------------------------------- --- /opt/chameleon/htdocs/common/session/session.php 2004-10-04 21:48:35.683423840 +0200 +++ /opt/chameleon2/htdocs/common/session/session.php 2004-10-04 21:46:40.028006136 +0200 @@ -56,6 +56,7 @@ global $gszSessSavePath; global $gszSessName; +global $bLockSession; $bDebug = false; $szDebugPage = isset( $_SERVER['ORIG_PATH_TRANSLATED'] ) ? basename( $_SERVER['ORIG_PATH_TRANSLATED'] ) : 'not set'; $szDebugDir = "f:/ms4w/"; @@ -90,7 +91,7 @@ mkdir($szSessionDir); } - if ( (PHP_OS == "WINNT" || PHP_OS == "WIN32") ) + if ( (PHP_OS == "WINNT" || PHP_OS == "WIN32") || $GLOBALS['bLockSession'] ) { $i=0; while ($i < ini_get("max_execution_time") - 2 ) //wait at most 2 seconds less than the execution time for the lock @@ -132,7 +133,7 @@ { debug_msg("Closed()"); } - if ( (PHP_OS == "WINNT" || PHP_OS == "WIN32") ) + if ( (PHP_OS == "WINNT" || PHP_OS == "WIN32") || $GLOBALS['bLockSession'] ) { $szLockFile = $GLOBALS['gszSessSavePath']."/sess_".$GLOBALS["gszSessId"]."/lock"; if ($GLOBALS["bDebug"]) @@ -240,7 +241,7 @@ { debug_msg("Destroy $szId"); } - if ( (PHP_OS == "WINNT" || PHP_OS == "WIN32") ) + if ( (PHP_OS == "WINNT" || PHP_OS == "WIN32") || $GLOBALS['bLockSession'] ) { $szLockFile = $GLOBALS['gszSessSavePath']."/sess_".$GLOBALS["gszSessId"]."/lock";
Changed target to 1.99 RC 1.
um. I was under the impression that session locking just *worked* in linux, but that is perhaps only when using the default file-based session handler. Raising priority, this needs to be in RC1.
test on linux and then implement patch.
Thanks Andreas. I've added your patch (more or less) to session.php with no adverse effects on linux (that I can tell). Can you please comment in this bug to indicate if the patch works for you?
Created an attachment (id=60) [details] session lock patch against htdocs/common/session.php, CVS version 2004-11-21 Paul, thanks for your efforts. But I'm afraid when applying my previous patch the wrong lines of your CVS code were affected. Attached is a new patch that will fix things again. Further suggestion: $SESSION['bLockSession'] should maybe be true by default.
applied patch. For now, I would be more comfortable leaving the default to be false because I haven't tested this extensively (I've tested in the sample apps but I haven't tried to set up a frames-based sample yet).