Description
The following change: symfony/symfony@50ec828 (origin PR: symfony/symfony#10908) wraps the entire request in a transaction to prevent multiple requests from manipulating the same session, creating a race condition. This is bound to create problems for many users as 1) Laravel 4 never calls close() on the session handler, effectively never commiting the transaction, preventing any database changes to take effect, and 2) many users do not use a separate database exclusively for sessions.
This change seems to be aimed at a bugfix release of Symfony 2.4 so it will take effect in Laravel 4.1 apps - and is already taking effect for people who do not have minimum-stability set to stable.
Just calling close() instead of save() in the session middleware class might solve the problem, but you still have the problem that your entire app lifecycle is going to be wrapped in a database transaction. A possible solution would be to write our own DatabaseSessionHandler to prevent further incompatibilities from propagating into Laravel.
Another change to keep an eye out for is this PR: symfony/symfony#10931 which optionally creates an entirely separate PDO instance for session management if no PDO instance is passed to the handler.
If you're currently having problems with your database changes not saving in a 4.1 app:
- In your project's composer.json, change minimum-stability to stable, then do a composer update.
- If you can't change minimum-stability to stable, add the following to your composer.json's require block:
"symfony/http-foundation": "2.4.*@stable"
If you want to avoid this problem in 4.2 beta:
Add the following to your composer.json's require block: "symfony/http-foundation": "2.5.0-BETA1" and run composer update. BETA2 has the new PdoSessionHandler which introduces this problem. This is obviously only a short-term solution as we figure out how to deal with this in Laravel.