On Tue, 2006-02-07 at 03:12, Iain Pople wrote: > Rafael Martinez Guerrero wrote: > > > Some time ago, we tried a version of the session handler that did what > > you suggest and we had big problems with transactions that were not > > finnished and waiting for a commit. After a while all connections to the > > database were in a 'waiting' state and the system stopped working > > because we used max_connections to the DB. > > > > This shouldn't really happen. From the PHP manual: > > "Note: Using pg_close() is not usually necessary, as non-persistent > open connections are automatically closed at the end of the script." > > http://php.planetmirror.com/manual/en/function.pg-close.php > > And from the session_write_close page: > > "Session data is usually stored after your script terminated without the > need to call session_write_close()" > > http://php.planetmirror.com/manual/en/function.session-write-close.php > > So the write function should be called automatically at the end of every > page.
It sounds logical, but what it happened is what I said, so something else has to influence how sessions behaves and I cannot say what :( > > > As I said, we have been using the code I sent for a long time without a > > problem and we generate several million transactions a day. > > > > The only situation where it could not work properly will be if from the > > same session/browser/client/user we generate to calls in parallel to the > > session table, that need to run a select to get some data that will be > > processed to update the table. > > > > I can not see how this can happen with squirrelmail. Anyone with any > > input to this? > > > > There is a fundamental difference how an application behaves with file > based sessions and db sessions without locking. Because file sessions > use the OS file locking, session access becomes serialised. This is also > alluded to in the PHP manual: > > "as session data is locked to prevent concurrent writes only one script > may operate on a session at any time. When using framesets together with > sessions you will experience the frames loading one by one due to this > locking. You can reduce the time needed to load all the frames by ending > the session as soon as all changes to session variables are done." > > http://php.planetmirror.com/manual/en/function.session-write-close.php > > In squirrelmail, if you are using file based sessions, one frame will > load before the other. The frames will not load simultaneously as a > result of the serialised session access. > > When using DB sessions without locking i observed the following problem: > [............] > > When a user logs in for the first time they have no entries in the > userprefs table. On the first login some default values are written into > their preferences. I found there was a race condition between the 2 > squirrelmail frames. Both frames were trying to insert a "hililist" > entry. e.g. > > INSERT INTO userprefs VALUES ('username', 'hililist', 'a:0:{}'); > > This conflicted with the PRIMARY KEY constraint so a database error was > generated. > > This is a direct result of the non-serialised access to sessions when > databases are used with locking. > Userprefs do not get updated via the sessions code. This is another problem that I have seen. It's true that something happens sometimes with the update of userprefs and an error is logged in the database : 'duplicate key violates unique constraint "userprefs_pkey"', but I think is not important because the database is doing its job and controls and prevents that one value gets inserted when it already exist in the database. This error with userprefs has been logged 10.821 times in our system since 01.01.2005 and we have had around 6.500.000 logins in the system. I have not get a single conflict with the PRIMARY KEY constraint in the session's table. > So squirrelmail relies on the serialised behaviour that file sessions bring. > > >> I also had to patch the PEAR DB.php code to force it to open a new psql > >> connection every time pg_connect is called. Otherwise the transaction > >> stuff above doesn't work. e.g. > >> > >> pg_connect($dsn, PGSQL_CONNECT_FORCE_NEW) > >> > > > > We use $db = DB::connect($dsn, false);. The false value will set the > > second parameter to false and the system will use the defaults settings > > (one of them (persistent boolean FALSE), so we do not use persistent > > connections. > > There is a difference between using persistent connections and forcing > new connections. > > From the PHP manual: > > "If a second call is made to pg_connect() with the same > connection_string as an existing connection, the existing connection > will be returned unless you pass PGSQL_CONNECT_FORCE_NEW as connect_type." > > http://php.planetmirror.com/manual/en/function.pg-connect.php > > Persistent connections just mean that when you call pg_close it doesn't > actually close the connection. > > The PGSQL_CONNECT_FORCE_NEW is needed for any DB calls with > transactions. e.g. > > SESSION A SESSION B > pg_connect > > BEGIN TRANSACTION; > ... pg_connect > ... BEGIN TRANSACTION (Error) > ... > COMMIT; > > Session B will generate a DB error because it is already in the middle > of a transaction (From session A). > Would not this be a problem only if you call the second pg_connect from the same script?. One apache process generates one connection to the database and the same apache process can not run another script until it finnish with the one that is been processed. So when the script is finnish, the connection will be close and the next script will have to open a new one because we are not using persistent connections. A persistent connection will not be destroyed after the script is finnish but PHP will insert a ROLLBACK as the last command just incase a transaction is not finnish so two different scripts wont't mess with eachother cheers :) -- Rafael Martinez, <[EMAIL PROTECTED]> Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 -- squirrelmail-users mailing list Posting Guidelines: http://www.squirrelmail.org/wiki/MailingListPostingGuidelines List Address: squirrelmail-users@lists.sourceforge.net List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
