rfc:session-lock-ini
Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
rfc:session-lock-ini [2014/02/01 23:40] yohgaki |
rfc:session-lock-ini [2017/09/22 13:28] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== PHP RFC: Introduce | + | ====== PHP RFC: Introduce |
* Version: 1.6 | * Version: 1.6 | ||
* Date: 2014-02-02 | * Date: 2014-02-02 | ||
* Author: Yasuo Ohgaki, yohgaki@ohgaki.net | * Author: Yasuo Ohgaki, yohgaki@ohgaki.net | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
Line 25: | Line 25: | ||
**proposal 3: unsafe_lock** | **proposal 3: unsafe_lock** | ||
- | Add unsafe_lock option for concurrent script execution. Currently, script execution is serialized when session is used. unsafe_lock=on allows script access session data concurrently. When lazy_write=on, | + | Add unsafe_lock option for maximum |
+ | |||
+ | Suppose there is concurrent access from a same client Connection A and B with unsafe_lock=On , lazy_write=On. | ||
+ | |||
+ | Connection A Connection B | ||
+ | ↓ ↓ | ||
+ | Open Session | ||
+ | ↓ ↓ | ||
+ | Login Does not care auth status. Just read session. | ||
+ | ↓ ↓ | ||
+ | Close Close (Session data unchanged) | ||
+ | |||
+ | Auth info set by Connection A never deleted by Connection B. Read only session achieves similar execution, but it has to wait lock. Therefore, previous access became | ||
+ | |||
+ | Connection A Connection B | ||
+ | ↓ ↓ | ||
+ | Open Session | ||
+ | ↓ ↓ | ||
+ | Login ↓ | ||
+ | ↓ ↓ | ||
+ | Close | ||
+ | Open Session | ||
+ | ↓ | ||
+ | Does not care auth status. Just read session. | ||
+ | ↓ | ||
+ | | ||
+ | |||
+ | **Usage Tip for unsafe_lock=On: | ||
**proposal 4: lazy_destroy** | **proposal 4: lazy_destroy** | ||
Line 34: | Line 62: | ||
* Script B accessed to server with old session ID | * Script B accessed to server with old session ID | ||
- | Current session module(session_destroy()/ | + | Current session module(session_destroy()/ |
Even when old session ID is destroyed, script B can access server with old session ID. Without session.strict_mode=On, | Even when old session ID is destroyed, script B can access server with old session ID. Without session.strict_mode=On, | ||
Line 66: | Line 94: | ||
- | ===== Proposal 2 - lazy_wirte | + | ===== Proposal 2 - lazy_write |
Introduce lazy_write option to session_start() that enable/ | Introduce lazy_write option to session_start() that enable/ | ||
Line 89: | Line 117: | ||
For files save handler, PS_UPDATE_FUNC() is not needed as it can update mtime at PS_OPEN_FUNC(). Files save handler' | For files save handler, PS_UPDATE_FUNC() is not needed as it can update mtime at PS_OPEN_FUNC(). Files save handler' | ||
- | For memcache/ | + | For memcache/ |
- | Other save handlers should support PS_UPDATE_FUNC() API to update last access time. Otherwise, garbage correction may remove active sessions. Alternatively, | + | Other save handlers should support PS_UPDATE_FUNC() API to update last access time. Otherwise, garbage correction may remove active sessions. Alternatively, |
===== Proposal 3 unsafe_lock option===== | ===== Proposal 3 unsafe_lock option===== | ||
Line 97: | Line 125: | ||
Session module locks session data while executing script by default. This make sure session data integrity by serializing script execution. i.e. Only a script may have access to session data at the same time. | Session module locks session data while executing script by default. This make sure session data integrity by serializing script execution. i.e. Only a script may have access to session data at the same time. | ||
- | Current behavior | + | Current behavior |
For user defined save handlers, locking is up to users. Memcached session save handler has lock ini option for better performance by sacrificing integrity a little. Second proposal mitigates broken integrity by unlocked session data access. | For user defined save handlers, locking is up to users. Memcached session save handler has lock ini option for better performance by sacrificing integrity a little. Second proposal mitigates broken integrity by unlocked session data access. | ||
- | Introduce | + | Introduce |
unsafe_lock - FALSE by default. | unsafe_lock - FALSE by default. | ||
Line 111: | Line 139: | ||
Current behavior: | Current behavior: | ||
- | Open session data | + | Open session data |
+ | | ||
+ | Read session data | ||
| | ||
- | | + | (Script execution) |
- | ↓ | + | ↓ ↓ |
- | | + | Write session data ------------------ |
- | ↓ | + | |
- | Write session data | | + | Close session data |
- | | + | |
- | Close session data ------------------ | + | |
- | New behavior with lock=Off: | + | New behavior with unsafe_lock=On: |
| | ||
Line 235: | Line 263: | ||
- lazy_write=TRUE could improved 2 times or better performance by removing write() calls. | - lazy_write=TRUE could improved 2 times or better performance by removing write() calls. | ||
- lazy_write=TRUE provides better data consistency since only modified session data is written when session.lock=FALSE, | - lazy_write=TRUE provides better data consistency since only modified session data is written when session.lock=FALSE, | ||
+ | |||
**Cons.** | **Cons.** | ||
- Session behavior is changed. When lazy_write=Off, | - Session behavior is changed. When lazy_write=Off, | ||
- | - Programmers are responsible for ensuring data consistency when lock=FALSE. | + | - Programmers are responsible for ensuring data consistency when unsafe_lock=TRUE. |
**3) unsafe_lock** that control session data locking. | **3) unsafe_lock** that control session data locking. | ||
**Pros** | **Pros** | ||
- | - Simpler and faster than session_lock() API. e.g. This API requires additional access to data storage which make data handling more complex and slower. | + | - Maximum concurrency |
+ | - Programmer does not have to selectively start session. (i.e. read only or not) Simplify code. | ||
- Allow concurrency without explicit calls of session_commit(), | - Allow concurrency without explicit calls of session_commit(), | ||
+ | - Simpler and faster than session_lock() API. e.g. This API requires additional access to data storage which make data handling more complex and slower. | ||
**Cons** | **Cons** | ||
- Misuse of this feature could be a cause of bugs. | - Misuse of this feature could be a cause of bugs. | ||
+ | - Open all session with read_only=TRUE and reopen session for writing as it is needed, would be safer for average users. (We may better to promote this usage pattern) | ||
**4) lazy_destroy** that allows delayed session data deletion for concurrent accesses and reliable session_regenerate_id() operation. | **4) lazy_destroy** that allows delayed session data deletion for concurrent accesses and reliable session_regenerate_id() operation. | ||
Line 253: | Line 285: | ||
**Pros** | **Pros** | ||
- session_regenerate_id() becomes more reliable for reasons described below. | - session_regenerate_id() becomes more reliable for reasons described below. | ||
- | - Mitigate | + | - Ensures proper application behavior even when network connection is unreliable. This is important for mobile applications especially. |
- | - Ensure proper application behavior even when network connection is unreliable. This is important for mobile applications especially. | + | - Mitigates |
**Cons** | **Cons** | ||
Line 261: | Line 293: | ||
- | Please note that **lazy_destroy is mandatory for reliable session_regenerate_id()/ | + | Please note that **lazy_destroy is mandatory for reliable session_regenerate_id()/ |
Please propose alternative solution if you vote no to this proposal. This is security related change so there must be alternative solution. session_regenerate_id() cannot delete old session without delayed deletion or alternative solution if there is. | Please propose alternative solution if you vote no to this proposal. This is security related change so there must be alternative solution. session_regenerate_id() cannot delete old session without delayed deletion or alternative solution if there is. | ||
Line 267: | Line 299: | ||
===== Benchmark ===== | ===== Benchmark ===== | ||
+ | |||
+ | Note: read_only=on will yield better result than this. | ||
== lazy_write: on, unsafe_lock: | == lazy_write: on, unsafe_lock: | ||
Line 283: | Line 317: | ||
Please vote feature by feature. | Please vote feature by feature. | ||
- | The voting period is 2014/02/03 until 2014/02/10. | + | The voting period is 2014/02/12 until 2014/02/19. |
1,2) Introduce read_only, lazy_write to session_start() option. | 1,2) Introduce read_only, lazy_write to session_start() option. | ||
Line 291: | Line 325: | ||
</ | </ | ||
- | 3) Introduce unsafe_lock option. | + | 3) Introduce unsafe_lock |
<doodle title=" | <doodle title=" | ||
* Yes | * Yes | ||
Line 297: | Line 331: | ||
</ | </ | ||
- | 4) Introduce lazy_destroy option. | + | 4) Introduce lazy_destroy |
<doodle title=" | <doodle title=" | ||
* Yes | * Yes |
rfc/session-lock-ini.1391298020.txt.gz · Last modified: 2017/09/22 13:28 (external edit)