ID: 20449 Comment 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:
[General Message - Not Bug Specific] In the past 12 months, I've raised a number of bugs relating to session problems that could not be reproduced consistently with the standard reply of 'its been fixed in CVS/Try CVS version'. I've tried the new CVS version and problems still continue (but still erratically). Over time, I've noticed a lot of developers problems (bugs) seem to be related to the global $_SESSION variable and I personally feel that the most stable session module is still in PHP version 4.0.6 before introduction in the 4.1 series. I'm not a hardened programmer, so this is a call to the current and previous developers/maintainers to consider a complete design and code walkthrough of the 'session related' code. Personally, I feel sessions is one of the key feature areas of PHP and something that needs to be highlighted to both Zend and the community to be made 'rock-solid'. Thanks Nick Previous Comments: ------------------------------------------------------------------------ [2002-11-25 18:22:39] [EMAIL PROTECTED] After a good weekend we are having an incredible Monday. My code in place now uses serialize/unserialize. I also convert my arrays to strings with implode/explode before the serialization/unserialization process. I don't see any missing information anymore in my session table. I really think the session serialize code is at fault for this bug. Specifically I think it simply doesn't handle arrays. (perhaps objects but my object simply had the array in it. Removing the array from the object and not using objects did not work) This is an extremely serious bug that was costing us on average of about 30-50 orders a day. I am honestly not exaggerating on this figure. I tried the CVS version as late as 11-15-2002 and it still had the bug in it. Before that I was using the latest 4.2.3 version. I'd like a little feedback from the developers to at least say they are looking into it. I will try to assist in any way I can. However, as I have said before, it was very random and I myself never saw my session disappear. Also important to note is that I do not rely on Session Cookies so it is not related to cookies. Also, I tried doing the reset(arrayvar) after each session restoration as suggested on one of the session man pages. That too did not work. I hesitate to say but I really think it would be important to make note to people that the session code is not reliable. Perhaps in the man pages. I won't go to such length though as to warn them myself though I feel some duty to do so. Perhaps the bug only comes into play on high traffic servers. Either which way, not relying on the internal session code has made a huge difference. That in itself should prove something. ------------------------------------------------------------------------ [2002-11-25 11:46:34] [EMAIL PROTECTED] This seems to be exactly the same problem we are having with one particular visitor to one of my websites. He always has this problem, every time he logs in his session expires. I have gone through his client PC configuration very carefully, and cannot find anything unusual. What's more odd is that he used to be able to use my site without problems. Would this problem manifest itself at random, or would it affect specific PCs? I had assumed the problem was at his end until I read this message thread, and it looked strangely familiar. Jolyon ------------------------------------------------------------------------ [2002-11-22 16:20:08] [EMAIL PROTECTED] Just thought I'd add that we are having what - seems to be - the same problem. We are running on Solaris 8 and our sessions are being held in a tmpfs mount that's balanced across 4 sun 220's. PHP Version 4.2.2 and Apache 1.3.26 compiled staticly. We've been moving the session store method around thinking I/O was the issue but it hasn't helped. We've done NFS mounted share, local-only share on 1 220 (limiting the load-balancing for one site to only that box) and now tmpfs. Our sessions are rather large (at least for me) normally around 11,316 bytes with objects and arrays w/ members that are serialized objects. It's probably important to note that we are avoiding automatic serialize/deserialize of objects by doing $_SESSION['someName'] = serialize($Object) type stuff. In almost all cases the sessions are there, but a couple values are simply missing. If you need anyother info please let me know. ------------------------------------------------------------------------ [2002-11-21 21:52:36] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ [2002-11-21 15:29:24] [EMAIL PROTECTED] NULL ------------------------------------------------------------------------ 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