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

Rasmus Lerdorf wrote:

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.

I agree. We should be able to release resource explicitly. Session could make throughput awful w/o it. -- Yasuo Ohgaki