ID: 20449
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: redhat 7.3
PHP Version: 4.4.0-dev
New Comment:
Ok. I think I have a really good idea as to what the bug is.
I am pretty sure there is a bug in the session serialization functions.
(and perhaps the normal php serialize/unserialize function)
It appears that the serialization does not handle arrays 100%
correctly. It works some of the times, but sometimes, the arrays get
completely lost. (thus the reason why the cart variable suddenly
changes to null)
Over the last couple of days, I implemented my own session code. I
stopped using $_SESSION and used my own method. (exact same concept
though)
I now use $GLOBALS["MYSESSION"] and I use serialize and unserialize
along with a session start and session save function. I store to the
exact same mysql session table that I did with code before.
We noticed an immediate improvement in sales of about 10-20 per day.
We were struggling to get to the 70-80 mark. The day I implemented the
new session code, we received 95 orders, the next day we received 91.
Today we are over 100!
I do however, still notice some null carts though. I think the normal
php serialize/unserialize function has a problem as well. However, it
is obviously more stable than whatever the $_SESSION code uses. (I
would assume the session code uses the regular php serialize functions?
if so, then calling serialize directly and not letting php handle the
sessions at all is more reliable)
So today I have written some further code to preconvert arrays into
strings. Thus, I will only be passing a normal string to
serialize/unserialize since it seems to handle strings perfectly. My
session start and save functions do all the conversion of string->array
and vice versa. I'll drop a note in here tomorrow to report how that
goes.
As a side note: as a programmer, I realize that thinking there is a bug
in those functionns is one thing. I know that since I can't provide
code that breaks it, it will be damn hard to debug. My only thought is
that it works most of the time so why wouldn't it work every time. I
too would probably tell myself that I'm smoking crack and the bug must
be elsewhere. But, I've been debugging everything else for over a
month. My recent changes brought a dramatic increase in orders so I
have to conclude that the bug lies somewhere in the php session code.
Again, I'll let you know how serializing only a string goes and not
letting serialize get a hold of an array.
Previous Comments:
------------------------------------------------------------------------
[2002-11-21 15:29:24] [EMAIL PROTECTED]
NULL
------------------------------------------------------------------------
[2002-11-21 09:54:16] [EMAIL PROTECTED]
I just noticed something in my session table.
a:2:{s:4:"cart";N;s:10:"gobackpage";N;}
What does N mean?
------------------------------------------------------------------------
[2002-11-17 22:56:14] [EMAIL PROTECTED]
Changing my delimiter has not helped either.
This is really hard to reproduce. But it is happening. I don't know
if adding a second server to share the load will help or not. While we
will be adding a second server tomorrow, we really shouldn't have to.
What should I do next?
Josh
------------------------------------------------------------------------
[2002-11-17 17:32:18] [EMAIL PROTECTED]
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
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
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
