Re: session_reset() and session_abort() to send errors

On Tue, Mar 25, 2014 at 5:06 PM, Andrey Andreev <narf@devilix.net> 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