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:23] 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, | ||
Lazy session data deletion solves this issue. It also solves reliability issue of session_regenerate_id() on unreliable networks. | Lazy session data deletion solves this issue. It also solves reliability issue of session_regenerate_id() on unreliable networks. | ||
- | |||
Line 67: | 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 90: | 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===== | ||
- | |||
- | NOTE: Default files save handler will not support this, but PECL files_ext. For files save handler, this option does not do anything. (Is this needed? Just a few lines of difference) | ||
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 114: | 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 163: | Line 188: | ||
Since alternative option could impact performance a lot. This RFC chooses first option. | Since alternative option could impact performance a lot. This RFC chooses first option. | ||
- | By introducing this feature, session_regenerate_id(true) (delete old session) could be a default. | + | By introducing this feature, session_regenerate_id(true) ($delete_old_session) can be a default. |
+ | |||
+ | session_destroy() no longer deletes session data, but set destroyed flag. To force deletion, add $force_deletion option to session_destroy(). (Default: FALSE) | ||
Line 182: | Line 209: | ||
None for most applications. | None for most applications. | ||
- | lazy_destroy is enabled by default for reliable session_regenerate_id() operation. This could be issue for test scripts. | + | lazy_destroy is enabled by default for reliable session_regenerate_id() operation. This could be issue for test scripts. For this case set $delete_old_session=TRUE. |
+ | session_destroy() no longer deletes session data. Like session_regenerate_id(), | ||
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
Line 212: | Line 240: | ||
- session_commit()/ | - session_commit()/ | ||
- session_abort() - Implemented (5.6 and up). End session without saving session data. | - session_abort() - Implemented (5.6 and up). End session without saving session data. | ||
- | - session_regenerate_id() - It cannot be delete old session reliably without session.lazy_destroy. "delete old session" option default changed to TRUE by default. | + | - session_regenerate_id() - It cannot be delete old session reliably without session.lazy_destroy. "$delete_old_session" option default changed to TRUE by default. |
+ | - session_destroy() - Added " | ||
- session_create_id() - Create session ID using session module code. Added by as part of RFC patch. | - session_create_id() - Create session ID using session module code. Added by as part of RFC patch. | ||
- session_set_save_handler() - Additional functions/ | - session_set_save_handler() - Additional functions/ | ||
Line 234: | 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 252: | 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 260: | 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 266: | 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 282: | 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 290: | Line 325: | ||
</ | </ | ||
- | 3) Introduce unsafe_lock option. | + | 3) Introduce unsafe_lock |
<doodle title=" | <doodle title=" | ||
* Yes | * Yes | ||
Line 296: | Line 331: | ||
</ | </ | ||
- | 4) Introduce lazy_destroy option. | + | 4) Introduce lazy_destroy |
<doodle title=" | <doodle title=" | ||
* Yes | * Yes |
rfc/session-lock-ini.1391296988.txt.gz · Last modified: 2017/09/22 13:28 (external edit)