Re: [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory

From: Date: Mon, 20 Jan 2014 09:17:10 +0000
Subject: Re: [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hi Stas,

On Mon, Jan 20, 2014 at 5:50 PM, Stas Malyshev <[email protected]>wrote:

> > I'll write clearly that "end users" should never enable dangerous
> > options unless
> > developer explicitly allows it. I'll also write that developers are
>
> I don't think we should provide options that need disclaimers that say
> "do not use it unless in very rare cases". If you are experienced enough
> that you need this rare case, you can implement your own session handler
> that does that. Especially given that the only use case I have seen so
> far actually does not need this feature and works just fine with much
> safer and smaller feature (session unlock, aka session_discard, aka
> session_abort).


This is feasible option.
There is session_abort() already. It's nice to have session_unlock().
I'll add session_unlock(). It requires new save handler API, but API is
modified anyway.

I understand your discussion and anxiety. People do stupid things w/o
knowing what they are doing.

Yet, I would like to have "non transaction query" like session data
handling, since there are apps that work as it should without
additional/modified code and enjoy much better performance.

I'll change voting option so that people could vote feature by feature.
 There are 3 users including me who vote to this RFC. They have to
vote again.

I'll send mail when I finish editing the RFC, please hold to vote.

Regards,

--
Yasuo Ohgaki
[email protected]


Thread (42 messages)

« previous php.internals (#71313) next »