Hi Stas
On Mon, Jan 20, 2014 at 4:35 PM, Stas Malyshev <[email protected]>wrote:
> > It allows access to old session for certain amount of time. 30 seconds
> > would be enough for session.lock=off. 60 or more when session.lock=on.
> > I was about to allow access to deleted session for 90 seconds.
> > Configurable INI may be better. I'll make session.lazy_destroy a integer
> > config.
>
> It is irrelevant how long it is. Even 1 microsecond is long enough - if
> the app said session data should be gone, then they should be gone, not
> linger around and allow access to them. If you need access to that data,
> copy it into the new session.
>
I agree. If app delete it now, it should be delete immediately.
It is possible with session.lazy_destory=0.
Since server and client is not synchronized, there are edge case that
app may allow to access old session for a while. It should be allowed. IMO.
>
> > IIRC you're one of them who are preferred to have separate
> > implementation(?)
>
> I prefer not to have implementation for 2 out of 3 proposed "features"
> at all, because I think they will produce more problems than solutions.
> For the lazy-write feature, IMO it can be made global, or function (I
> actually prefer both) - but I see no reason to create a duplicate
> driver, if you don't want it turned on, turn off the option. I'm not
> sure what would be the reason to clone the driver. Do you have a
> reference for where it was asked so I could re-read it and recall what
> were the reasons for it? My memory may be failing me :)
> > No, they don't have to. They can ignore new features or implement them
> > all or part of them.
>
> This would be a bit confusing - you set an option, but some drivers
> would implement it, some would ignore it, so you never know what
> actually happens.
>
That's the reason why I would like to add new API to declare save handler
capability. If I know capability, I may assume what it does.
> > Shooting their own foot is possible, but let advanced users to enjoy
> > extreme performance!
>
> I don't think performance at he expense of reliability, data consistency
> and security should be our goal. Like I said, we could also make an
> option to ignore random number of file writes and claim it is a
> performance feature, but it would be useless, since there is no case
> where one would recommend to use it. I see no case where I would
> recommend anybody to use unlocked sessions - so why introduce it?
In previous mail, it is described good use case.
Without locking, scripts are executed concurrently.
When session.lock=off and session.lazy_write=on, scripts does not have
to wait session read() and only updated session is written back to storage.
For example, if session only store authentication information, it works
perfectly and there is no risk of authenticated(logged out session) remains
or un-authenticated session became an authenticated session.
We also should consider that memcache/memched have unlock option already.
Like databases allow query without transaction or transaction with less
consistency, session module may allow options that give more performance
at the cost of consistency. It's an option for developers. IMHO.
(Current session is the same as "serializable transaction isolation level"
only
database which is very slow and restrict concurrency.)
I'll write clearly that "end users" should never enable dangerous options
unless
developer explicitly allows it. I'll also write that developers are better
to detect
dangerous options if app does not support them. Is it enough, isn't it?
Regards,
--
Yasuo Ohgaki
[email protected]