Sessions Question

[bryan]

Hi folks,

I've got a question about sessions in PHP. I'm a *gulp* ASP coder, so
please bear with me.

I developed a PHP site a few months back that has a password protected
entry into a secure section. I'm using session variables to ensure
that track if a visitor has already logged in, and should therefore be
allowed to view a given page.

This week there was a problem with the site not having access to the
MySQL database the site uses. The hosting company sent me this message
as an explanation for the problem:

"the culprit seems to be the way that you are handing sessions on the
GPR_intro.php page. The sessions are not being terminated in a timely
manner which is causing a back log of processes on the MySQL service
and is causing it to fail. The best course of action would be to
terminate your sessions at a set interval rather then letting them time
out on their own."
Huh??? Isn't that how sessions are supposed to work? You set session
variables, and they will timeout in a set period of time. That's how
it works in ASP. That's how it works in ColdFusion. Is that not the
case in PHP?

It sounds to me like a bogus answer, so I'd like some "expert"
opinions.

Thanks in advance for your help!

- Bryan

[Alvaro G Vicario]

*** br***@chameleon-systems.com wrote/escribió (13 Jan 2005 08:46:31
-0800):

Huh??? Isn't that how sessions are supposed to work? You set session
variables, and they will timeout in a set period of time. That's how
it works in ASP. That's how it works in ColdFusion. Is that not the
case in PHP?

I suppose you use the built-in session handler, don't you? Write a script
with <? phpinfo() ?> as its only content and find the "session" table.
Check the session.save_ha ndler directive. Is the server configured to store
sessions in a MySQL database?

As about zombie MySQL processes, MySQL connections are closed when the
script ends. The only exception are persistent connections (unless PHP is
configured not to allow them). Keeping a session open just means the data
will be stored for more time, which should not be an issue for any database
engine.

--
-- Álvaro G. Vicario - Burgos, Spain
-- Thank you for not e-mailing me your questions
--

[R. Rajesh Jeba Anbiah]

br***@chameleon-systems.com wrote:
<snip>

This week there was a problem with the site not having access to the
MySQL database the site uses. The hosting company sent me this message as an explanation for the problem:

"the culprit seems to be the way that you are handing sessions on the
GPR_intro.php page. The sessions are not being terminated in a timely
manner which is causing a back log of processes on the MySQL service
and is causing it to fail. The best course of action would be to
terminate your sessions at a set interval rather then letting them time out on their own."
Hmm... I don't think, your setup is complex to handle custom DB
based session handler. Perhaps there might be some issue with
persistent connection as someone suggested.

But, I also have the opinion that they wrongly mean session file
locking which can be fixed with proper usage of
<http://in2.php.net/session_write_c lose>
Huh??? Isn't that how sessions are supposed to work? You set session variables, and they will timeout in a set period of time.

That's configurable (session.gc_max lifetime). Looking at the manual
might be of more help <http://in2.php.net/session>

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[bryan]

Álvaro,

Thanks for the response. I ran the phpinfo command like you suggested,
and here's what I got:

Directive Local Value Master Value
session.save_ha ndler files files

That seems to indicate to me that MySQL isn't involved in the equation
at all, right?

Bryan

Alvaro G Vicario wrote:

*** br***@chameleon-systems.com wrote/escribió (13 Jan 2005 08:46:31
-0800):

Huh??? Isn't that how sessions are supposed to work? You set session variables, and they will timeout in a set period of time. That's how it works in ASP. That's how it works in ColdFusion. Is that not the case in PHP?
I suppose you use the built-in session handler, don't you? Write a

script with <? phpinfo() ?> as its only content and find the "session" table. Check the session.save_ha ndler directive. Is the server configured to store sessions in a MySQL database?

As about zombie MySQL processes, MySQL connections are closed when the script ends. The only exception are persistent connections (unless PHP is configured not to allow them). Keeping a session open just means the data will be stored for more time, which should not be an issue for any database engine.

--
-- Álvaro G. Vicario - Burgos, Spain
-- Thank you for not e-mailing me your questions
--

[Alvaro G Vicario]

*** br***@chameleon-systems.com wrote/escribió (13 Jan 2005 12:53:08
-0800):

Directive Local Value Master Value
session.save_ha ndler files files

That seems to indicate to me that MySQL isn't involved in the equation
at all, right?

Certainly: it's using the default handler, that's it, session data is
stored into files.

In any case, check GPR_intro.php in case there's actually something wrong
with your code.
--
-- Álvaro G. Vicario - Burgos, Spain
-- Thank you for not e-mailing me your questions
--

[bryan]

Thanks for the help, Álvaro. It just didn't seem to make sense to me
that the sessions would affect the database. The memory, or file space
on the web server I could understand, but not he database.

I'll double check my code just to be sure, but it's pretty straight
forward. When a person logs in, I do a session_start() at the top of
the page, then $_SESSION["userid"] = $sUserID further down in the code.

On the protected pages, I also do a session_start() , then I do a
isset($_SESSION["userid"]) check to see if the person is logged in or
not.

That's all there is to it.

Bryan

Alvaro G Vicario wrote:

Certainly: it's using the default handler, that's it, session data is
stored into files.

In any case, check GPR_intro.php in case there's actually something wrong with your code.
--
-- Álvaro G. Vicario - Burgos, Spain
-- Thank you for not e-mailing me your questions
--