Re: [PHP] Re: SESSION variables: How much is too much?

[kranthi]

I prefer to reduce SESSION usage as much as possible. but I dont hesitate to
use them if need arises.
Points to note

   - Execution time: Only session_id is stored on the client's computer, and
   the actual data is stored on the server. so it will take nearly same time to
   process 100 session vars and 1 session var.
   - Security: While passing data trough hidden form fields, it is easy for
   the user to be change it. but its impossible (the user can change the
   session_id though) for the user to change the data stored in a session.
   - register_globals: i always set this off. but my host turned this on.
   had to spend 2 full days to find out what the problem was.

coming back to you issue: IMHO storing stuff like MaxDisplayRecords,
DefaultDisplayRecords, etc., in a SESSION var is the best solution.
alternatives being

   - Hidden fields: this will add to unnecessary network traffic.
   - Use separate file: Why use a separate file if PHP does the job for you?
   - Use the database: If you have an existing connection this is OK. But
   this will become a bottle neck if u dont have an existing connection

Re: [PHP] Re: SESSION variables: How much is too much?

[D.M.Jackson]

Hi,

OK, I did a count on the session.inc file and there appears to be 37 
variables accessed through the $_SESSION object.  By and large they all 
appear to be scalar variables that contain a counter or a path or a boolean. 
Nothing that looks like a big object.  Mostly stuff like MaxDisplayRecords, 
DefaultDisplayRecords, Theme, DefaultTheme, CustomerId, RealName, 
CustomerBranch, Module, UserStockLocation, PageSize, AccessLevel, 
AttemptsCounter, Language, PageSecurityToken, DatabaseName...etc.
Initially, when you hit the index page the session.inc file is included. 
From there, depending on what choices you make from the options displayed it 
assembles a page by calling the a php file that calls the database if 
needed, includes a header.inc file and a footer.inc file and builds the 
appropriate html for the body and of course, includes the session.inc file.
My question is, assuming 37 variables of this type in the 
session.inc file, at what level of concurrent user access do you consider 
changing the way you do business here.  Bare in mind that I don't comprehend 
a whole lot about server and database clustering and big enterprise big iron 
stuff like that.  I'm just a guy trying to learn how to write decent php 
code that I don't have to be embarassed of when I shift gears in a new 
direction to add a marketable skill in my career development path.

Thanks,
Mark






Paul M Foster pa...@quillandmouse.com wrote in message 
news:20090709010528.gx14...@quillandmouse.com...
 On Wed, Jul 08, 2009 at 06:55:24PM -0500, Shawn McKenzie wrote:

 D.M.Jackson wrote:
  Thanks guys.  I was just wondering if it was common practice to pass 
  all
  those variables in the SESSION object or if I was following a bad 
  example
  because it was the first time that I had seen so many variables passed 
  this
  way.  If this is the typical way of handling this in php then I don't
 have a
  problem with it, I just wanted to make sure that I wasn't getting off 
  to a
  bad start and picking up bad habits while learning php.
 
  Thanks,
  Mark

 Again, it depends upon whether you need those variables in the next
 page for example.  Think of a wizard, where you fill some values in a
 form, click next, fill more values, click next, etc and then click
 finish.  You may want to pass the values from each page to the next via
 the session and ultimately have them all available in the last page.
 There are others ways to do this, such as adding them as hidden inputs
 in the next pages, but I personally would use sessions.

 One other example might be user info, id, username, firstname, lastname,
 current access role etc.  You may use these on every page, so once you
 retrieve them from the db, you can store them in the session.  Any other
 info like email, age, register date whatever, you can retrieve only when
 needed.

 Just to provide a counterpoint to this, I would discourage using
 $_SESSION for more than absolutely necessary. If I have a situation such
 as Shawn mentions above, I pass values via hidden fields in the form.
 Most of the forms I create are backed by a database, so mostly I capture
 data from there. In addition, you can serialize data you wish to save
 and store it in a database or hidden field, and then unserialize it upon
 painting the next page.

 If I'm not mistaken, there's a limit to the data which can be stored in
 a session variable. I don't want to mistakenly hit that limit and wonder
 what happened. And besides, I just think $_SESSION should be reserved
 for *special* cases.

 And, as mentioned before, it's worthwhile asking yourself if you
 *really* need to remember a bunch of information from page to page. The
 need to do so may well be a result of lazy programming habits.

 Paul

 -- 
 Paul M. Foster 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: SESSION variables: How much is too much?

[Paul M Foster]

On Wed, Jul 08, 2009 at 06:55:24PM -0500, Shawn McKenzie wrote:

 D.M.Jackson wrote:
  Thanks guys.  I was just wondering if it was common practice to pass all
  those variables in the SESSION object or if I was following a bad example
  because it was the first time that I had seen so many variables passed this
  way.  If this is the typical way of handling this in php then I don't
 have a
  problem with it, I just wanted to make sure that I wasn't getting off to a
  bad start and picking up bad habits while learning php.
 
  Thanks,
  Mark
 
 Again, it depends upon whether you need those variables in the next
 page for example.  Think of a wizard, where you fill some values in a
 form, click next, fill more values, click next, etc and then click
 finish.  You may want to pass the values from each page to the next via
 the session and ultimately have them all available in the last page.
 There are others ways to do this, such as adding them as hidden inputs
 in the next pages, but I personally would use sessions.
 
 One other example might be user info, id, username, firstname, lastname,
 current access role etc.  You may use these on every page, so once you
 retrieve them from the db, you can store them in the session.  Any other
 info like email, age, register date whatever, you can retrieve only when
 needed.

Just to provide a counterpoint to this, I would discourage using
$_SESSION for more than absolutely necessary. If I have a situation such
as Shawn mentions above, I pass values via hidden fields in the form.
Most of the forms I create are backed by a database, so mostly I capture
data from there. In addition, you can serialize data you wish to save
and store it in a database or hidden field, and then unserialize it upon
painting the next page.

If I'm not mistaken, there's a limit to the data which can be stored in
a session variable. I don't want to mistakenly hit that limit and wonder
what happened. And besides, I just think $_SESSION should be reserved
for *special* cases.

And, as mentioned before, it's worthwhile asking yourself if you
*really* need to remember a bunch of information from page to page. The
need to do so may well be a result of lazy programming habits.

Paul

-- 
Paul M. Foster

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php