Re: Re: #3793 [Ana->Opn]: session.gc_maxlifetime

On Mon, 19 Aug 2002, Yasuo Ohgaki wrote: > Zeev Suraski wrote: > > I don't think that's the way to do it at all. In theory, it's no > > problem to track whether changes were made to the session data, and > > perform the write at the end of the request, only if we tracked a > > change. That's only in theory, though, since with the fancy new > > $_SESSION array, there's no way to track whether changes were made to > > the session data. I can try to think of a solution, though. > > > > I don't see any advantage in reading the session data, comparing it with > > the serialized currently-active data, and comparing the two. It'll > > probably be slower than simply writing the whole thing all over again. > > > > It could be faster just saving data always. > > All depends on situation, session data storage, session data server > loads, size of session data, number of concurrent accesses to servers, > how often session data is changed and so on. > > BTW, I don't see strong needs of ommiting write when session data > is not changed. I'm point it out that it can be done, and possibly > faster, with user defined session save handler if one need it. > > For my applications, session data is changed often enough. I > don't need the feature omitting session write automatically. But there are still a lot of cases where not writing the session data at the end of a request will simplify things quite a bit and also be much more efficient. I am not too concerned about not writing based on whether or not data changed, I'd like the user to be able to specify that it shouldn't be written through session_readonly(). This avoids locking issues in complex framed sites and avoids a lot of useless writes when the author knows there will be no changes or wants to make sure that any inadvertent changes are not written. -Rasmus