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

Hi Stas, On Mon, Jan 20, 2014 at 5:50 PM, Stas Malyshev <smalyshev@sugarcrm.com>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 yohgaki@ohgaki.net