Session GC fix: save session.modified field as UTC so our comparisons work.

Had to tweak statusnet.ini to remove the DB_DATAOBJECT_MYSQLTIMESTAMP bitfield constant on session.modified; while it sounds like a useful and legit setting, it actually just means that DB_DataObject silently fails to pass through any attempts to explicitly set the value. As a result, MySQL does its default behavior which is to insert the current *LOCAL* time, which is useless.
This was leading to early GC west of GMT, or late GC east of it. Early GC could at worst destroy all live sessions (whoever's session *triggered* GC is fine, as the session then gets saved right back.)
This commit is contained in:
Brion Vibber 2011-01-27 12:27:31 -08:00
parent 433ec21119
commit a7abb2323e
2 changed files with 16 additions and 1 deletions

View File

@ -87,6 +87,7 @@ class Session extends Memcached_DataObject
$session->id = $id;
$session->session_data = $session_data;
$session->created = common_sql_now();
$session->modified = common_sql_now();
$result = $session->insert();
@ -108,6 +109,7 @@ class Session extends Memcached_DataObject
$orig = clone($session);
$session->session_data = $session_data;
$session->modified = common_sql_now();
$result = $session->update($orig);

View File

@ -513,7 +513,20 @@ profile_id = K
id = 130
session_data = 34
created = 142
modified = 384
modified = 142
; Warning: using DB_DATAOBJECT_MYSQLTIMESTAMP (256) causes DB_DataObject
; to SILENTLY REMOVE ATTEMPTS TO SET THIS FIELD DIRECTLY, which is pretty
; bad because the default behavior for auto-updated TIMESTAMP fields is
; to use local time. Local time can't be compared to UTC in any useful
; way, so doing that breaks session GC.
;
; Instead we'll use the plain datetime settings so it'll actually save the
; UTC value we provide when updating.
;
; Long-term fix: punch MySQL in the face until it understands that local
; time is a tool of the cyber-devil.
;
;modified = 384
[session__keys]
id = K