[eluser]xoiv[/eluser]
I created a session that creates, maintains and closes sessions in the database, but when the user closes the browser, does not close the session in the database, is there any way to control this?
[eluser]Abel A.[/eluser]
Edit your cofig file:
Code: $config['sess_expire_on_close'] = TRUE;
The above tells the user's browser to delete the session cookie when it closes the browser. Though you can't force the user to delete the cookie, it's all browser dependent. Most browsers will delete the cookie though. You should probably run a Garbage Collector to delete old sessions, say older than 1 day since most users won't have their browser opened the entire day.
[eluser]xoiv[/eluser]
I am using the $config['sess_expire_on_close'] = TRUE; but closes the session at the client level, but in the database does not delete the session record to close the browser.
[eluser]Abel A.[/eluser]
Yes, there's no way to tell if the user closed the browser. One way is to run an ajax request when the user closes the browser, but it will cause too many issues if the user has more than one tab opened. Like I said, run a GC to delete old sessions. CI stores the last time a user uses the session in last_activity. You can narrow it down to the hour.
Example:
Code: $timeframe = now() - 3600; //one hour
$sql = "Delete FROM ci_sessions WHERE last_activity < '".$timeframe."'";
[eluser]xoiv[/eluser]
thanks friend, I think good solution =)
[eluser]CroNiX[/eluser]
They will eventually get deleted from the database. They mimic true php sessions in that regard (those don't get deleted from the server right away, either). They go into PHP's "session garbage collection" which randomly deletes them according to your hosts php.ini settings for it.
Although, I usually have that query running in a daily cron job to delete sessions older than 48 hours because PHP's GC sucks.
[eluser]Abel A.[/eluser]
[quote author="CroNiX" date="1339027327"]They will eventually get deleted from the database. They mimic true php sessions in that regard (those don't get deleted from the server right away, either). They go into PHP's "session garbage collection" which randomly deletes them according to your hosts php.ini settings for it.
Although, I usually have that query running in a daily cron job to delete sessions older than 48 hours because PHP's GC sucks.[/quote]
PHP's GC is bad, it runs on probability; there's not set time on when it will run. Though you can always change that, but most folks don't bother with that.
[eluser]SPeed_FANat1c[/eluser]
Today we got masive session disconnects from session something like each 10 minutes or more user had got disconected, it was imposible to work for him, but only runnning about 10-20 users at a time. Could that be because of lot of session rows? There were like 150 000 rows in CI_sessions table. I deleted them all, but also my collegue restarted apache server. Probably apache restart solved the problem, but I am not sure. He also said something about transactions, there were not finished many.
Everything solved for now, but its interesting - does the ci_sessions table could cause lot of disconnects with that much rows?
[eluser]Abel A.[/eluser]
No, 150k rows is not that many, but there's always other factors. It all depends on how many users are online, etc. Apache is usually a problem on high traffic sites, consider looking into nginx.
[eluser]SPeed_FANat1c[/eluser]
Quote:Apache is usually a problem on high traffic sites
The traffic was not hight, 10-20 users online, probably the problem was with database, since it throwed out - becuase of too many slots taken or something like that. There were script running in cron each 5 minutes, and it somehow took the slots probably. Something with max conenctions limit there was, when we stopped script in cron, system started to work better again.
|
