The warning means that you did a request with an old session cookie, while another request (second open Window?) had rotated the session id.
For the session data, it means you have a concurrency issue, the other request may have updated the session data, so the session changes from this request are not written, so they are lost.
If you rely heavily on session data and need concurrent window support, you need to take this into account.
The error I don't understand. Asssuming that is the INSERT query (you left the query out of the message), that can only happen when a duplicate key is generated. This is not impossible, but highly unlikely. So not sure what causes this.
As to your remark about being logged in: the sessione expiry mechanism is the same for all drivers, there is no difference between any of the backends.
thanks for your reply and sorry for my late answer.
This Problem still exists.
The Fuelphp Lofiles of my Projects are full with Messages from this Kind of Errors ...
The WARNING - 2017-01-21 00:06:36 --> Session update failed, session record recovered using previous id. Lost rotation data?
Error occurs less often but the "ERROR - 2017-01-21 00:24:01 --> shutdown - SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '89d0194073b270bd3b270a736837cbb0' for key 'PRIMARY' with query:" occurs very often ...
For example
"ERROR - 2017-12-31 18:05:41 --> shutdown - SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'eb9de139f3bca00930f48c709eb1aa5e' for key 'PRIMARY' with query: "INSERT INTO `sessions` (`session_id`, `previous_id`, `ip_hash`, `user_agent`, `created`, `updated`, `payload`) VALUES ('eb9de139f3bca00930f48c709eb1aa5e', 'eb9de139f3bca00930f48c709eb1aa5e', 'bd0caa3d88ca3926b51dec2d18c45c32', 'Mozilla/5.0 (Windows NT 10.0; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0', 1514739941, 1514739941, 'a:3:{i:0;a:7:{s:10:\"session_id\";s:32:\"eb9de139f3bca00930f48c709eb1aa5e\";s:11:\"previous_id\";s:32:\"eb9de139f3bca00930f48c709eb1aa5e\";s:7:\"ip_hash\";s:32:\"bd0caa3d88ca3926b51dec2d18c45c32\";s:10:\"user_agent\";s:73:\"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0\";s:7:\"created\";i:1514739941;s:7:\"updated\";i:1514739941;s:7:\"payload\";s:0:\"\";}i:1;a:0:{}i:2;a:2:{s:15:\"flash::messages\";a:2:{s:5:\"state\";s:3:\"new\";s:5:\"value\";a:0:{}}s:29:\"flash::__session_identifier__\";a:2:{s:5:\"state\";s:6:\"expire\";s:5:\"value\";s:40 in /var/www/html/fuel/core/classes/session/db.php on 238
The rotation issues happen if you have an app with concurrent requests, for example ajax calls, in combination with having multiple windows open.
In this situation it can happen that one call uses session key A which gets rotated to B, while the parallel call still uses A because it doesn't know about the rotation. In this case the session is recovered using the "previous_id" in the session record. You can increase the rotation time to make this appear less often.
Your second issue puzzles me.
The session DB driver only inserts a new session record if the read when the session was started failed. If it does, it generates a new session key, and the chances of a collision on a generated session token are very slim.
All our application (as in 100% of them) use db backed sessions, and I've never seen this in the 7 years I've worked with Fuel.
How do you use Session. Do you autoload it, or start it manually in your code? Do you let Fuel handle everything, or do you call read and write manually?
I use the default Session Configuration shipped with Fuelphp i think. The only Thing i changed was that i use the db driver instead of the file driver.
I've double checked our live apps, they all use the standard sessions table with the session_id primary key, and none has even a single insert error in the logs.
Do you have multiple Fuel application in the same domain (a.example.org and b.example.org), and using cookies at domain level (so both apps see each others session and get confused)?
What Fuel version is your app on? The session classes have been refactored about 6 months ago, so if you are on 1.8.0, switching to 1.9/dev could fix your problem.
It is stable, it will become 1.8.1 soon (as soon as I have time that is).
Donate
