[RESOLVED] Session question ?

quecoder

Hello ,
Sessions cookies are removed once the browser is closed or the user has navigated away from the website .. that's good , but I have two questions :

1 - Cookie only is removed , and the flat file of the session is still stored on the server although I will never need it as the cookie is removed from the user machine and I can not identify him again ,... why PHP still keeps the flat file that holds the data ?

2 - to make sessions last for longer time(not to die after closing browser) , should I use directive: session.cookie_lifetime or session.gc_maxlifetime or both ?? I got an answer that I should use only session.cookie_lifetime. BUT :

I read that session.gc_maxlifetime directive is responsible for removing the flat files after a certain number of seconds ( default is 1440 = 24 minutes ) .. so , no point when setting the cookie to last for longer time(that holds just the SID ...name of the flat file ) via session.cookie_lifetime if the other directive will remove the flat file that holds the actual data ....

bretticus

quecoder;10879623 wrote:
Hello ,
Sessions cookies are removed once the browser is closed or the user has navigated away from the website ..

Actually, the browser does not kill the cookie when you surf away from the website. You have to close the browser.

quecoder;10879623 wrote:
that's good , but I have two questions :

1 - Cookie only is removed , and the flat file of the session is still stored on the server although I will never need it as the cookie is removed from the user machine and I can not identify him again ,... why PHP still keeps the flat file that holds the data ?

Because php (the webserver actually) has no idea that you have closed the browser or surfed away. This is why sessions are cleaned up after a specific amount of inactivity time.

quecoder;10879623 wrote:
2 - to make sessions last for longer time(not to die after closing browser) , should I use directive: session.cookie_lifetime or session.gc_maxlifetime or both ?? I got an answer that I should use only session.cookie_lifetime. BUT :

I have been using session.gc_maxlifetime. Last time I checked this seemed to let me choose how long to keep session data before garbage cleanup.

quecoder;10879623 wrote:
I read that session.gc_maxlifetime directive is responsible for removing the flat files after a certain number of seconds ( default is 1440 = 24 minutes ) .. so , no point when setting the cookie to last for longer time(that holds just the SID ...name of the flat file ) via session.cookie_lifetime if the other directive will remove the flat file that holds the actual data ....

Not really sure, but yes, a session cookie should last as long as the browser is open IMHO. Thus, I'm only worried about garbage collection.

I'm sure a PHP session guru will chime in and give comments.

nrg_alpha

quecoder;10879623 wrote:
2 - to make sessions last for longer time(not to die after closing browser) , should I use directive: session.cookie_lifetime or session.gc_maxlifetime or both ?? I got an answer that I should use only session.cookie_lifetime

While I am not knowledgable on flat files and how they work, I think the whole point of general $_SESSION variables it to indeed die upon browser closure.

Otherwise, it would probably be best to resort to setting up $_COOKIE instead. Of course, I could be wrong on this. But since sessions are using PHPSESSID cookies (which are temp cookies), they are built this way just for the purpose of quick disposal afterward.. (unless I am misunderstanding something).

Cheers,

NRG

Weedpacket

nrg_alpha wrote:
I think the whole point of general $_SESSION variables it to indeed die upon browser closure.

The session as a whole dies because it needs both the server and the browser to keep it alive, but neither really knows what the other is doing (due to HTTP's stateless nature - which itself is the reason why session management is necessary). In particular, as bretticus states, the server can't tell if the client is still holding up its end. All it can do is go "hmm... they've been quiet a long time ... I wonder if they're still here? .... I mean, it's been like half an hour now and I haven't heard a peep out of them ... I guess they must have gone."

So if a given session has been untouched for more than gc_maxlifetime seconds, it's regarded as eligible for garbage collection.

For performance, the server does not check to see if there are any sessions that have been inactive for more than gc_maxlifetime every time a request is made. Instead, every time session_start() is called, there is a certain probability that it will check. So there is a chance that a session file will remain sitting around for longer that gc_maxlifetime, but (unless the browser does happen to come back) it will eventually get cleaned out.

bretticus

For performance, the server does not check to see if there are any sessions that have been inactive for more than gc_maxlifetime every time a request is made. Instead, every time session_start() is called, there is a certain probability that it will check. So there is a chance that a session file will remain sitting around for longer that gc_maxlifetime, but (unless the browser does happen to come back) it will eventually get cleaned out.

Thanks for the insight. Good to know.

nrg_alpha

Thanks for the heads up, weedpacket.. makes understanding those issues much clearer.

Cheers,

NRG

quecoder

Weedpacket;10879653 wrote:
The session as a whole dies because it needs both the server and the browser to keep it alive, but neither really knows what the other is doing (due to HTTP's stateless nature - which itself is the reason why session management is necessary). In particular, as bretticus states, the server can't tell if the client is still holding up its end. All it can do is go "hmm... they've been quiet a long time ... I wonder if they're still here? .... I mean, it's been like half an hour now and I haven't heard a peep out of them ... I guess they must have gone."

So if a given session has been untouched for more than gc_maxlifetime seconds, it's regarded as eligible for garbage collection.

For performance, the server does not check to see if there are any sessions that have been inactive for more than gc_maxlifetime every time a request is made. Instead, every time session_start() is called, there is a certain probability that it will check. So there is a chance that a session file will remain sitting around for longer that gc_maxlifetime, but (unless the browser does happen to come back) it will eventually get cleaned out.

I understand now 😃 .. but :
1- Do I still need to set both directives and don't depend on this probability when wanting to keep the session last longer?

2- Are the following directives the ones that determine this probability :

session.gc_probability = 1
session.gc_divisor     = 1000

and this means that for every 1000 session_start() call the unused files will get deleted ?!

Weedpacket

quecoder wrote:
1- Do I still need to set both directives and don't depend on this probability when wanting to keep the session last longer?

If you want the session to persist after the browser is closed, then yes, you do need to set cookie_lifetime to something other than 0. Of course, that doesn't help people who's cookies are turned off (because the session ID is passed in the URL instead). Generally, if you want something to persist between sessions (which is what it sounds like you want), it would be better to store the data in the database, and give the client a cookie with a unique ID that can be used to retrieve that data.

2- Are the following directives the ones that determine this probability :

Well, that's what it says in php.ini. 🙂

and this means that for every 1000 session_start() call the unused files will get deleted ?!

Not quite: it means that on every call to session_start there is one chance in a thousand that a garbage collection will happen. So after it expires there's actually a 50-50 chance it will be collected within 700 requests.

nrg_alpha

Now I have never mucked around with server / ini settings. But it just hit me.. when I do site testing locally, this would explain the pile up of sessions in a folder when I am examining stuff in explorer (not Internet Explorer mind you.. the windows explorer).

I always wondered about that pileup.. suppose the garbage collector fell asleep on the job 😉

Cheers,

NRG

Weedpacket

nrg_alpha wrote:
I always wondered about that pileup.. suppose the garbage collector fell asleep on the job 😉

Nah, you're just not giving it a chance 🙂. If you're starting a session on average once every five minutes while testing locally you'd have do so non-stop for nearly sixty hours for there to be a 50-50 chance that the garbage collection will run.

Drakla

[man]session_set_cookie_params[/man] will let you temporarily change the lifetime of the cookie - but of course you're still playing roulette with the garbage collector.

quecoder

Weedpacket;10880027 wrote:
Nah, you're just not giving it a chance 🙂. If you're starting a session on average once every five minutes while testing locally you'd have do so non-stop for nearly sixty hours for there to be a 50-50 chance that the garbage collection will run.

Sorry , but can you please let me know how did you calculate it ?

quecoder

I will make the topic "Resolved" as all my main questions were answered ..
Thanks to all that helped out 🙂

Weedpacket

quecoder wrote:
Sorry , but can you please let me know how did you calculate it ?

With a 1-in-1000 chance for gc to run on any given session start, there is a 50-50 chance that it will run within 700 session starts. 700*5 minutes is 58 1/3 hours.