As Marek has stated a number of times, the session options in php.ini
are meant to be set to reasonable values for the usage pattern for your
server, in order that you can achieve a balance between a /tmp or
/var/tmp of several zillion kilobytes, and a constant 100% cpu usage as
the gc routine
Hendrik Schmieder wrote:
Hello,
we have a severe problem with seesions.
We use Apache 1.3.31 with PHP 4.3.9 as Apache module in Windows 2000
In our php.ini we have
session.gc_probability = 100
session.gc_dividend= 100
Should be session.gc_divisor. And you need to start at least one other
Marek Kilimajer schrieb:
Hendrik Schmieder wrote:
Hello,
we have a severe problem with seesions.
We use Apache 1.3.31 with PHP 4.3.9 as Apache module in Windows 2000
In our php.ini we have
session.gc_probability = 100
session.gc_dividend= 100
Should be session.gc_divisor
OK , changed in
Hendrik Schmieder wrote:
Marek Kilimajer schrieb:
Hendrik Schmieder wrote:
Hello,
we have a severe problem with seesions.
We use Apache 1.3.31 with PHP 4.3.9 as Apache module in Windows 2000
In our php.ini we have
session.gc_probability = 100
session.gc_dividend= 100
Should be
[snip]
If you are right, then this is a severe design bug.
Depends on your point of view. It is a sideeffect of loading current
session (and thus accessing it) before the session gc is called.
So the question is, should the session module give up on current session
just because it should
Graham Cossey wrote:
[snip]
If you are right, then this is a severe design bug.
Depends on your point of view. It is a sideeffect of loading current
session (and thus accessing it) before the session gc is called.
So the question is, should the session module give up on current session
just
Marek Kilimajer schrieb:
Hendrik Schmieder wrote:
Marek Kilimajer schrieb:
Hendrik Schmieder wrote:
Hello,
we have a severe problem with seesions.
We use Apache 1.3.31 with PHP 4.3.9 as Apache module in Windows 2000
In our php.ini we have
session.gc_probability = 100
session.gc_dividend= 100
Graham Cossey schrieb:
[snip]
If you are right, then this is a severe design bug.
Depends on your point of view. It is a sideeffect of loading current
session (and thus accessing it) before the session gc is called.
So the question is, should the session module give up on current session
Hendrik Schmieder wrote:
Anyway , if the apache service is stopped (I am not speaking about a
crash) all session files must be deleted.
Why? Why should users loose their sessions just because I need to
restart web server?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit:
Marek Kilimajer schrieb:
Hendrik Schmieder wrote:
Anyway , if the apache service is stopped (I am not speaking about a
crash) all session files must be deleted.
Why? Why should users loose their sessions just because I need to
restart web server?
OK,
good point.
So I redrew the request for
Hendrik Schmieder wrote:
Marek Kilimajer schrieb:
Hendrik Schmieder wrote:
Anyway , if the apache service is stopped (I am not speaking about a
crash) all session files must be deleted.
Why? Why should users loose their sessions just because I need to
restart web server?
OK,
good point.
So I
Hendrik Schmieder wrote:
Graham Cossey schrieb:
[snip]
If you are right, then this is a severe design bug.
Depends on your point of view. It is a sideeffect of loading current
session (and thus accessing it) before the session gc is called.
So the question is, should the session module
M. Sokolewicz wrote:
Hendrik Schmieder wrote:
Ok, I think you're all missing a few points here...
First of all,
every time a session is started/accessed/written to/whatever, PHP makes
a check, it calculates , using gc_probability/gc_divisor, if it should
run the gc (Garbage Collector) on this
There is a difference between the session file existing, and the user
still having a valid session.
If the timeout has occurred, and the file has not been deleted, when the
user accesses it, the session will not show up in $_SESS[]. Which for
all intents an purposes, means the session has been
Make sure it's not just a cookie-problem related to server name. The shopping
cart session for original-remote-control.co.uk is different from the shopping
cart for www.original-remote-control.co.uk. If this is your problem, I think
you can fix it by changing how you call setcookie.
Of
15 matches
Mail list logo
