On 16 Jan 2012, at 22:51, Haluk Karamete wrote:

> Hi, in ASP, sessions expire when the client does not request an asp
> page for more than 20 min. (The 20 min thing is a server level setting
> - which can be changed by IIS settings )  And sessions work out of the
> box.
> I use sessions a lot. So, most likely, I would keep that style in my
> PHP apps too.
> I read the following about PHP sessions...  I wanted to know how
> accurate this info is.
> <quote>
> The default behaviour for sessions is to keep a session open
> indefinitely and only to expire a session when the browser is closed.
> This behaviour can be changed in the php.ini file by altering the
> line:
> session.cookie_lifetime = 0
> If you wanted the session to finish in 5 minutes you would set this to:
> Listing 23 Keeping a session alive for five minutes (listing-23.txt)
> session.cookie_lifetime = 300.
> Remember to restart your web server after making this change.
> </quote>

That's totally accurate, except that it doesn't touch upon how sessions are 
cleaned up...

> Now, if this info is correct and it is this simple, why do we have
> some elaborate posts like this one?
> http://stackoverflow.com/questions/520237/how-do-i-expire-a-php-session-after-30-minutes

...which explains that post. The session.cookie_lifetime is simply the expiry 
time that will be set on the cookie that specifies the visitor's session ID. 
That ID is used as the unique identifier on the server in the session storage 
system (defaults to files of serialized data). If you want to have more precise 
control over the session lifetime (though I can't see any reason why you would 
need to) then you can write your own session handler and implement the timeout 
logic yourself. You could also handle it by storing a timestamp in the session 
and using that to decide whether the session data should be considered valid 
(as described in the accepted answer on that post).

> What do you do when you write a PHP app that relies on sessions? how
> do you manage the server memory allocation issues?
> Say you wanted to keep session vars alive for 20 min ( from the last
> request from the client ) and you wanted your server to completely
> empty the session if there no request, no new php page is requested
> from that client within that next 20 min. And if a client requests a
> page say on the 19th min, session gets extended another 20 from that
> time on, just like the ASP works.

The only reason there would be memory allocation issues is if you're storing 
huge amounts of data in the session. If you are then I'd suggest that you 
either re-architect your application so you don't need to, or implement a 
custom storage mechanism for that data that doesn't use the session system.

> My second question on session is abut keeping sessions apart from one
> another - if such a concept exists...
> Let's say you have a session var FirstName in app1 and another session
> variable exactly named as FirstName in app2.
> how do you keep them seperate?
> In ASP, I create a virtual app at the IIS server - assigning a virtual
> dir path to the app, and from that point on, any page being served
> under that virtual path is treated as an isolated ASP app and thus the
> sessions are kept isolated and not get mixed up by asp pages that do
> not live under that virtual app path.

I don't know much about the way ASP implements sessions but I highly doubt 
there is anything significantly different in there to the way PHP does it. For 
all intents and purposes the isolation of a given user's session is guaranteed 
by the use of cookies. As I mentioned earlier, the session ID is stored in a 
cookie. Cookies are not shared between domain names, so there is no way that 
two sites, or "applications", could use the same session [1].


[1] This is not entirely true, but since it requires some nasty trickery to 
make it happen it's not something you need to worry about unless it sharing 
sessions is required which is incredibly rare and almost certainly another sign 
of poor architecture!

Stuart Dallas
3ft9 Ltd
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to