Re: session_reset() and session_abort() to send errors
Hi Andrey,
On Fri, Apr 4, 2014 at 7:07 PM, Andrey Andreev <[email protected]> wrote:
> On Fri, Apr 4, 2014 at 12:48 PM, Yasuo Ohgaki <[email protected]> wrote:
> > Hi Andrey,
> >
> > On Tue, Apr 1, 2014 at 6:20 PM, Andrey Andreev <[email protected]> wrote:
> >>
> >> >> Well, I just re-checked it and does indeed just call
> >> >> php_session_initialize(), so what's the point? Shorthand for
> >> >> session_abort() && session_start() ?
> >> >
> >> >
> >> > Yes, it's an API for it.
> >> > It's more efficient than user land functions as it requires needless
> >> > close and open (and initialization required to open).
> >>
> >> I'm confused now, does it call open() or does it not?
> >> If it doesn't - it's unsafe.
> >
> >
> > It's safe as long as handler locks data during read/write.
> > Example is memcached save handler with unlocked session.
>
> I had something other in mind and you didn't really answer my
> question, but ... there you have it - it can be unsafe even by your
> own words. :)
>
Regarding to safety of session data management, session management is _not_
safe anyway. Locked session does not guarantee data consistency due to
nature of HTTP session management. Locked session provides a litter better
consistency. That's all and no more than that. i.e. It's false sense of
safety.
That said better is better. That's the reason why I'm proposing various
_better_
way of management than now.
>> If it does - it's unclear, redundant and optimizes by silently
> >> discarding already open resources (without properly closing them).
> >>
> >> Either way, I like efficiency but I also see it as flawed.
> >
> >
> > Save handler may lock/unlock session data. There is no standardized
> > way for it.
> >
> > Since there would not be lock option for session manager, I don't mind
> > removing it. There is not much point to have it without lock option for
> > session manager. I would like to have session_gc() than session_reset().
>
> This sounds a bit like you're proposing some kind of a trade
> agreement. When you put it that way, I'd also rather have session_gc()
> instead of session_reset(), but that's not the point. My initial
> argument was that these features need to be brainstormed here on
> internals and there was no discussion about them at all.
It's not trade. session_gc() is mandatory and I'll add it anyway :)
Periodic GC is much better way than probability based GC. There must
be API for it. I think there wouldn't be argument for this.
Regards,
--
Yasuo Ohgaki
[email protected]
Thread (15 messages)