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

Hi! > In previous mail, it is described good use case. > Without locking, scripts are executed concurrently. If the scripts are going to write the session, they can not execute concurrently, because that creates race condition and at least one of the states will be lost. If they don't intend to write, they can just drop the lock immediately after reading, that's why we talked about having function for that. Neither works well with no locks at all. > 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 It doesn't work perfectly for scripts that modify authentication information. And writing an app where there are race conditions in authentication mechanism is very poor idea, security-wise. For performance in read-only case, there's a simple solution which does not jeopardize stability, see above. > We also should consider that memcache/memched have unlock option already. I would not recommend anybody then to use them with that option. This only can lead to trouble. It's running shared data structure without any locks. If it's not specially designed for it, you'll get in trouble - and it will always be undebuggable, unreproducible and happen in the worst possible moment, when the system is loaded and too many things are happening at once. > Like databases allow query without transaction or transaction with less If you are using DB without transactions, you must ensure consistent state in your app, or accept data inconsistency. Data inconsistency may be ok if your data is not that important - but if it's security-sensitive, it is not a good idea. Sessions usually deal with security-sensitive data. > 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). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227