|
1 |
| -UPGRADE FROM 2.5 to 2.6 |
| 1 | +UPGRADE FROM 2.5 to 2.6 |
2 | 2 | =======================
|
3 | 3 |
|
4 | 4 | Form
|
@@ -101,3 +101,30 @@ Security
|
101 | 101 | @security.token_storage => getToken()
|
102 | 102 | @security.token_storage => setToken()
|
103 | 103 | ```
|
| 104 | + |
| 105 | +HttpFoundation |
| 106 | +-------------- |
| 107 | + |
| 108 | + * The `PdoSessionHandler` to store sessions in a database changed significantly. |
| 109 | + - By default, it now implements session locking to prevent loss of data by concurrent access to the same session. |
| 110 | + - It does so using a transaction between opening and closing a session. For this reason, it's not |
| 111 | + recommended to use the same database connection that you also use for your application logic. |
| 112 | + Otherwise you have to make sure to access your database after the session is closed and committed. |
| 113 | + Instead of passing an existing connection to the handler, you can now also pass a DSN string which |
| 114 | + will be used to lazy-connect when a session is started. |
| 115 | + - Since accessing a session now blocks when the same session is still open, it is best practice to |
| 116 | + save the session as soon as you don't need to write to it anymore. For example, read-only AJAX |
| 117 | + request to a session can save the session immediately after opening it to increase concurrency. |
| 118 | + - As alternative to transactional locking you can also use advisory locks which do not require a transaction. |
| 119 | + Additionally, you can also revert back to no locking in case you have custom logic to deal with race conditions |
| 120 | + like an optimistic concurrency control approach. The locking strategy can be chosen by passing the corresponding |
| 121 | + constant as `lock_mode` option, e.g. `new PdoSessionHandler($pdoOrDsn, array('lock_mode' => PdoSessionHandler::LOCK_NONE))`. |
| 122 | + For more information please read the class documentation. |
| 123 | + - The expected schema of the table changed. |
| 124 | + - Session data is binary text that can contain null bytes and thus should also be saved as-is in a |
| 125 | + binary column like BLOB. For this reason, the handler does not base64_encode the data anymore. |
| 126 | + - A new column to store the lifetime of a session is required. This allows to have different |
| 127 | + lifetimes per session configured via session.gc_maxlifetime ini setting. |
| 128 | + - You would need to migrate the table manually if you want to keep session information of your users. |
| 129 | + - You could use `PdoSessionHandler::createTable` to initialize a correctly defined table depending on |
| 130 | + the used database vendor. |
0 commit comments