Re: [phplib] PHP4 session problems From: Max A. Derkachev (kot <email protected>)
Date: 01/29/01

Hello Shawn,

Sunday, January 28, 2001, 10:26:31 PM, you wrote:

SB> Next came the problems of working with sessions within frames. I was
SB> getting the following error in 2 out of my 3 frames (although not always in
SB> the same frame):

SB> Database error: Invalid SQL: insert into active_sessions ( sid, name, val,
SB> changed ) values (...)
....
SB> page_close() in all the frames. So I got rid of the page_close()'s in the
SB> navigation frames and things got a lot better.

Right. If you have 3 concurrent read/write session objects, you'll
come into a trouble. There should be only one read/write, others
should be read only - otherwise all they would try to write stuff at
the same time. And worse, if you have some data in session in the
main frame that you'd like to survive through the next pages, but
one of the other frames (which indeed knows nothing about things happen in
the main frame) writes its variant of the session to the database
after the main frame does. It would replace all the stuff the main
frame wrote with its own stuff, so all the registered variables from
the main frame would be lost forever.

SB> But not perfect. I still get
SB> the error once in a while and I have no idea why!

That strange problem become happen after, I guess, 4.0.2 or so ...
Haven't dig into depths, though.

SB> So I decided that the solution was to use PHP4 sessions. I had heard about
SB> an implementation being in the CVS tree so I went to check it out. Man was
SB> I disappointed! There were 3 different implementations and no indication as
SB> to the differences, state of completion, stability, etc. Nothing! I
SB> couldn't believe it. I thought this whole problem would have been dealt
SB> with by now, but instead it looks like it's in its infant stages and not
SB> very organized at that.

Well, I believe that's the right point, and I feel that it's partly a
my fault ( :). Still going to write a readme about my variant
(session4_custom.inc). I believe it's quite stable (btw. maybe people
who are using it drop me a word about their feelings? ). Just made some
rewrite to allow use of native php4 storage containers (it has used
only PHPLib CT_* containers before). I suppose I'll organize my
thoughts in a README soon.

SB> I'll probably try one of the
SB> others. Of course, I may just be creating a new set of problems for myself,
SB> but I've got to do something.

Well, you could try my variant (don't blame me for promotion things :)
I tried to make it compatible with the old session.inc as it could be
possible. The installation is similar to old session.inc. The main
differences are how auto_init is used (there is no use of sess->in
now, so every thing you initialize in auto_init file should be tested
with sess->is_registered() first before initialization), and the use
of the User class (it is no longer inherited from Session - I supplied
new user class in user4.inc that should work with the new Session).
Some changes shoud be made to page.inc (look at CVS), because PHP4
saves session automatically, and the page_close() call no longer
needed if you don't use User class.

SB> Now, onto the _real_ problem with PHP4 sessions. The problem only occurs
SB> when using frames, but it's a biggy. With PHPLIB sessions, each frame has
SB> its own copy of all the registered variables, including $sess and $auth.
SB> When one frame changes a registered variable, that change is _not_ visible
SB> to the other frames. With PHP4 sessions, the frames share one set of
SB> registered variables, and changes to a registered variable in one frame are
SB> immediately visible to the other frames.

I doubt. Only SAVED changes to registered variables become visible to
other pages (and every page) - the same thing as in the PHPLib.
The changes could not be visible after a page is actually sent to a
client, even if some changes are made at the moment in other script.
Session state is saved after the page is processed, during the page
shutdown. And any page that is in the same session context gets all
variables saved by the previous script accessed the session.

SB> This rears its head in an ugly way with default authentication. Default
SB> authentication depends on the fact that each frame has its own copy of the
SB> $auth object. If they share an object, then the real authentication in one
SB> frame interferes with the default authentication in the other frame(s).
SB> Both frames are trying to set the $auth instance variables to different
SB> values. Needless to say, the results will be unpredictable at best. You'll
SB> either get the login form in all the frames, default authentication in all
SB> the frames, or some seemingly random combination.

Right. That's why you should be VERY accurate with frames - PHP4 saves
session state automatically and you can not regulate it with
page_close, as in PHPLib (I guess that's the reason for feature
request for readonly session). That's why I don't use frames. Use
session in only one frame, and don't use it at all in other frames, if
you're using PHP4 native sessions (even with any PHPLib implementation
for PHP4 sessions).

SB> The other potential problem that I can see with PHP4 sessions is that when
SB> registered objects are restored in a new page, _all_ of the instance
SB> variables will be restored, not just the ones specified as having
SB> persistent slots. Any object that depends on this behaviour will now break.

I don't believe so. You'll have those properties (specified with
persistent_slots) along with other properties - so they'll be
accessible in any case. But new serialization (using native PHP's
session_encode) works MUCH MUCH faster then the old - I guess 2 times
faster or more, depending on the structure you want to serialize.

SB> Anyway, my real concern is how PHP4 sessions will affect PHPLIB as a whole.

Yes. There would be big changes. The work on merging PHPLib into PEAR
is currently in progress. 

-- 
Best regards,
Max A. Derkachev mailto:kot <email protected>
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
http://www.Books.Ru -- All Books of Russia
 

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>