On Tue, Mar 25, 2014 at 5:06 PM, Andrey Andreev <[email protected]> wrote:
> Hi,
>
> I had previously requested the removal of these 2 functions based on
> lack of discussion about them (or at least I found none). My request
> was ignored because I had to tell "why it's not needed", which I don't
> think is the right approach for a new feature that somebody just
> decided to commit, but regardless ... here's a good reason:
>
> From what I understand, session_reset() not only discards changes to
> $_SESSION and not just re-reads the data, but re-initializes the whole
> session. This includes calls to open(), read(), which include opening
> file pointers, setting locks, checking session ID validity, etc. I
> don't know how safe that is to do internally, but with a userland
> session handler, it means discarding previously open connections/file
> pointers, locks and whoever knows what else a developer might've
> cached, assuming that open(), read() would only be called once.
> It would've also been better IMO if the function was called
> session_restart() instead, because of the above-described behavior.
>
> I also don't like that these 2 functions kind of make sessions to look
> like a traditional database transaction, or at least I'd hate it to
> see code that uses them for the wrong purpose, but that's rather
> philosophical ... I do see them as useful for resetting the
> application to a certain state in case of an error, but in that
> context - session_abort() alone should be sufficient.
>
Yup, I agree that I dont really see a use case for session_reset().
The implementation looks strange.
Yasuo, could you clarify please ?
Julien