Description: ------------ I use this code to setup the session: HTTP_Session2::useTransSID(false); HTTP_Session2::useCookies(true); HTTP_Session2::setContainer('MDB2', array( 'dsn' => &$this->db, 'table' => 'session', 'autooptimize' => true ) ); HTTP_Session2::start('mysite'); HTTP_Session2::setExpire(3600); HTTP_Session2::setIdle(900); if (HTTP_Session2::isNew()) { } else if (HTTP_Session2::isExpired()) { HTTP_Session2::destroy(); } else if (HTTP_Session2::isIdle()) { HTTP_Session2::destroy(); } And after my code i'm doing this at the end HTTP_Session2::updateIdle(); This code is mainly from the examples. As long as the session is valid all is fine. but if the session expires there is no data found because the timestamp is as followed: db timestamp is 1279881181 and the query timestamp is 1279887764. At the end if the session should be written to database the check if the record exists found it, because only the id is checked. but the update failed, because the timestamp. Expected result: ---------------- Using a new session or a cleared old session. Actual result: -------------- Every call result in a clear session, and the data is never saved.

So wait, you want to write data to a session after it expired? How would you do that with PHP $_SESSION and session_*() calls?

I always use $_SESSION, but i don't want to write to a expired session. The problem is, the session seems to be expired and the db record is still there. the destroy doesn't deleted it. the other methods from the mdb2 module finds this record and tries to write to db. but they didn't use a new session, they want to update the old with a other timestamp that prevents the update. so every new call to pages ends in a session that can't be saved. or maybe i'm using http_session2 in a wrong way, its not impossible :)

Afaik, HTTP_Session2::destroy() (which wraps session_destroy()) only removes references, it doesn't create actual data. So for example, even if you used straight PHP sessions this wouldn't happen. The files would still be there in (session.save_dir) until the garbage collector is run. Check: HTTP_Session2::setGcMaxLifetime() HTTP_Session2::setGcProbability() http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Sessio n2.php?revision=267739&view=markup

Sorry, to clarify: > Afaik, HTTP_Session2::destroy() (which wraps session_destroy()) > only removes references, it doesn't create actual data. ... doesn't delete actual data.

yes, but i use the mdb2 container which register a destroy function to session_destroy call, or am i wrong? and this function should delete the session data? http://svn.php.net/viewvc/pear/packages/HTTP_Session2/trunk/HTTP/Session2/Container/MDB2.php?view=markup at line 261.

Yes, but here's your misunderstanding: 1) HTTP_Session2 registers a new session-handler, in your case the MDB2- based one. 2) This session-handler is configured through regular PHP settings (session.*), including garbage collection (gc) - e.g. probablity and lifetime. Depending on your settings (which I assume you didn't really touch), the garbage collection is run. 3) The function HTTP_Session2::destroy() has nothing to do with that in the container. The one in the container is configured/ran using session.gc_* stuff, or using HTTP_Session2::setGcMaxLifeTime() and HTTP_Session2::setGcProbability() (PROBABILITY) ;-) I hope this clears things up.

Thank you for taking the time to write to us, but this is not a bug. Btw, I totally agree - this could be better documented. If you have the urge to contribute something, let me know. Feel free to re-open with some info, or whatever.

Ok, thanks for your explanation. That helped and i figured something out that was my misstake. I used the pause function to update the session data, i thought. but pause wrote the data and closed the db connection. And i used pause in my code before i called updateidle. So the session was always idle after the idle time from the session start. That was one of my problems and the gc functions cleared some of the rest. Thanks!

Still one of the problem resists. The Session seems to be expired, but the module can't update the record. here is some logging: 13:43:40 Open... 13:43:40 Connect... 13:43:40 Read... SELECT data FROM session WHERE id = 'b38aa7b96aff956da71878556f6eea42' AND expiry >= 1280490220 Result: Empty result... 13:43:40 Update Idle... 13:43:40 Write... 13:43:40 Check... SELECT COUNT(id) FROM session WHERE id = 'b38aa7b96aff956da71878556f6eea42' 13:43:40 Update... UPDATE session SET expiry = 1280491660, data = '...' AND expiry >= 1280490220 Affected Rows: 0 13:43:40 Close... The database field expiry has the value 1280490046 for this record. As you can see the read method didn't found the record and result in a empty session. The write method checks for the session, found it and tries to update it, but can't update it. I don't know why this happens, but this is the core problem of all my problems. btw the write method at line ~258 should use the exec method of mdb2. currently it uses the query method. this way you can't see the affected rows. and the statements are only inserts or updates at this point.

Can you open a separate issue for query() vs. exec() - with a patch if possible. I'll think about your other issue, I need a fresh set of eyes on this.

A new bug is opened for the query vs exec stuff. Any idea whats the problem and how to fix it?

Sorry, but your problem does not imply a bug in PEAR itself. For a list of more appropriate places to ask for help using PEAR, please visit http://pear.php.net/support/ as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PEAR. The idea is - when a session expired it's gone. You need to configure the garbage collector and then the record vanishes. It's expected behavior that a session which expired cannot be updated anymore through the session handler.