Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- Objects and sessions
March 9, 2005, 11:45 am
rate this thread
I have two PHP questions concerning objects stored in sessions.
I'm developing an intranet for a client to be run in a Redhat 8/Apapche
2/PHP 4/MySQL environment. All pages are password protected and I get
to choose how to authenticate and layer permissions.
My first thought to this affect is to use the User table of the mysql
database to maintain site users rather than create a redundant users
table in some other database. MySQL does a great job with permissions,
and since I have root access, it seemed the natural course of action.
The user logs in by supplying name and password via an HTML form and
the authentication functions attempt a mysql_connect() with the
supplied arguments. If mysql_connect() returns greater than false, the
Since I couldn't store the mysql_connect() in $_SESSION, I created an
object to store all of my "state" values, and it seems to work. (Though
I'm not certain why you can't store a db connection directly into
session vars, but can when they're embedded in an object.)
My (current) code for instantiating the object and storing it is as
require( "php_includes/class_web_page.php" );
if ( !$_SESSION["page"] )
$page = new Web_page();
$_SESSION["page"] = &$page;
$page = $_SESSION["page"];
...blah, blah, blah...
Question 1: I'm not sure that I'm ever killing this object and freeing
up its memory. When the session ends, will the object die with it?
Being a non-public application with low traffic, a small memory leak
won't show up for a long while, but I don't want to find out in a year
or so that I have to re-engineer the whole thing due to my current lack
Question 2: My first thought was to store a reference to the object
(&$page) in $_SESSION. (Coming from C, I figured I was storing a memory
address and that the interpreter automatically dereferenced it.) My
thinking was that storing the memory address was lighter on the
$_SESSION size. Reading up on PHP, I find that no, referencing in PHP
essentially duplicates the variable. (I'm not really passing by
reference, am I?) Am I now making a doubly wide memory allocation by
using my reference? Combine that with question 1, am I now creating a
memory leak twice as large?
Generally speaking, I'm pretty sure that I'm going about this with my
head up my a$$? If a more elegant/efficient solution should be taken,
I'd appreciate the criticism.
Re: Objects and sessions
Not really, but when you store an object with references to other objects,
you store the other objects too - so...
....or you could use the __sleep method to do something similar.
Re: Objects and sessions
I suppose I should try to sell you my product... (see my sig) :-)
This seems like a good idea, but you have to ask youself if you want
each user to have access to database stuff? I mean, are you placing things
in those tables that don't belong there? If not, then it's probably
not a bad idea. Personally, I'd have a bad feeling about it.
Careful about invalid logins -vs- database connection problems.
Another potential "gotcha" is using other stuff with it, HTTP based
authentication may be a good route for an intranet because it works
with PHP applications that have no access control as well as Perl (shell
or even static HTML) This isn't an insurmountable deal, with apache and
mod_rewrite, though it is an extra step.
Downside of HTTP based is that there isn't a good way to log out.
Actually, I think this starts to explain question #1.
Session data is typically serialized and written to the filesystem
or in some cases, a database BLOB. I suppose it could be stored in shared
memory or something, but I've never seen that done. (Except maybe a
filesystem created on a block RAM device or something)
The session "ends" when the file is erased, PHP has some built in stuff
for removing session files, but you can actually remove them by
simply deleting the sess_ files from /tmp or /var/tmp or wherever
your PHP is putting them.
When an object is "alive", it is only valid during the page request,
after that it's frozen.
Try requiring a PHP class, creating an object and then storing it in a session.
After that, try loading the page (or another page) that uses the object from a
session BEFORE requiring the PHP class the object belongs to. This should prove
it's not been stored in memory as an object, (and also explain why you can't
store database connections in a session)
You'll get errors because the objects class isn't available. This is because
PHP is taking the session data (Have a look at one of it's session files) and
deserializing it, no associated class? Hmm.. panic time. Guess you could say
session objects just 'have no class' (yuk, yuk). (well, actually they sort
of do, in so far as they know WHAT class to populate, they just don't know
WHERE that class is)
Hopefully I'm not being critical. :-) Sessions data is rather confusing.
http://www.geniegate.com Custom web programming
email@example.com (rot13) User Management Solutions