ID: 20449
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: redhat 7.3
PHP Version: 4.4.0-dev
New Comment:
I set the gc_probability to 0. After 5 hours, I got another dozen
notifications that the cart failed. I even got a tech support
complaint from a customer.
My hunch is that the serializer is obliterating the array. One of the
recent things I started to do was to initialize $_SESSION["cart"] =
Array(); when they first enter the site. On the sessions that have
problems, the cart variable disappears. However, other session
variables still exist.
No where on the site do I attempt to destroy the session.
I'm going to change my | delimiter as I notice that the serializer uses
a | as a delimiter. I wonder if that could be it. (though, it works
most of the time)
I've made the other changes to the handler. I still see problems
though. Is there any particular user behaviour that could explain it?
I had someone suggest to me that a user double clicking the add to cart
button could do it. I don't see how though. Not only that, I've tried
clicking more than once myself and have never seen the problem.
Josh
Previous Comments:
------------------------------------------------------------------------
[2002-11-17 12:42:17] [EMAIL PROTECTED]
Ok. I will fix my handler using your suggestions. I'll get back to
you after a few hours of letting it work.
Josh
------------------------------------------------------------------------
[2002-11-17 12:40:32] [EMAIL PROTECTED]
I'm trying to provide as much as I can.
Here is a sample session from the dbase.
cart|a:1:{s:9:"161-00084";s:14:"White-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
A quick thought. I use the | as a delimiter to seperate the color-size
and quantity. Would my delimiter potentially screw up the unserialize
or serialize functions?
For multiple products here is a sample session.
cart|a:2:{s:9:"117-00717";s:20:"Black-Small_Medium|1";s:9:"117-00875";s:15:"Yellow-Medium|1";}affiliatename|s:0:"";cartposted|s:10:"addProduct";
------------------------------------------------------------------------
[2002-11-17 12:36:34] [EMAIL PROTECTED]
Missed a couple of words in the above. "will randomly be deleted" I
meant to write.
------------------------------------------------------------------------
[2002-11-17 12:35:37] [EMAIL PROTECTED]
Your handler isn't very good. As far as I can tell you never update
the expiry value which means that your sessions will randomly (because
the gc hook is called on a probability) after 5400 seconds (90 minutes)
after initial creation. A quick fix would be to never expire sessions
by setting:
session.gc_probability = 0
In your php.ini file. Or, better yet, fix your handler to update the
expiry time when writing to a session. This expiry time is supposed to
be idle session time, not an absolute the way you have it.
I would suggest letting MySQL handle the timestamp and using a schema
that looks like this:
id char(32) NOT NULL,
data text,
ts timestamp,
PRIMARY KEY (id)
And instead of that ugly INSERT/UPDATE thing you have for your write
hook, use:
$data = addslashes($data);
mysql_query("replace into $table (id,data) values('$id','$data')")
or error_log("write:
".mysql_error()."\n",3,"/tmp/errors.log");
The gc hook would just be:
function gc($max_time) {
global $table;
mysql_query(
"delete from $table where
UNIX_TIMESTAMP(ts)<UNIX_TIMESTAMP()-$max_time")
or error_log("gc: ".mysql_error()."\n",3,"/tmp/errors.log");
return true;
}
But try setting gc_probability to 0 just to verify that this is indeed
the cause of the lost sessions. If it is, then you need to slap
yourself hard as the code is doing exactly what you told it to do.
------------------------------------------------------------------------
[2002-11-17 12:19:36] [EMAIL PROTECTED]
I'm reopening this bug as I've provided more feedback.
Please yell at me if I'm not doing this right :)
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/20449
--
Edit this bug report at http://bugs.php.net/?id=20449&edit=1
