[ACCEPTED]-PHP: Storing 'objects' inside the $_SESSION-object

Accepted answer
Score: 139

I know this topic is old, but this issue 30 keeps coming up and has not been addressed 29 to my satisfaction:

Whether you save objects 28 in $_SESSION, or reconstruct them whole 27 cloth based on data stashed in hidden form 26 fields, or re-query them from the DB each 25 time, you are using state. HTTP is stateless 24 (more or less; but see GET vs. PUT) but 23 almost everything anybody cares to do with 22 a web app requires state to be maintained 21 somewhere. Acting as if pushing the state 20 into nooks and crannies amounts to some 19 kind of theoretical win is just wrong. State 18 is state. If you use state, you lose the 17 various technical advantages gained by being 16 stateless. This is not something to lose 15 sleep over unless you know in advance that 14 you ought to be losing sleep over it.

I am 13 especially flummoxed by the blessing received 12 by the "double whammy" arguments put forth 11 by Hank Gay. Is the OP building a distributed 10 and load-balanced e-commerce system? My 9 guess is no; and I will further posit that 8 serializing his $User class, or whatever, will 7 not cripple his server beyond repair. My 6 advice: use techniques that are sensible 5 to your application. Objects in $_SESSION 4 are fine, subject to common sense precautions. If 3 your app suddenly turns into something rivaling 2 Amazon in traffic served, you will need 1 to re-adapt. That's life.

Score: 114

it's OK as long as by the time the session_start() call 5 is made, the class declaration/definition 4 has already been encountered by PHP or can 3 be found by an already-installed autoloader. otherwise 2 it would not be able to deserialize the 1 object from the session store.

Score: 35

HTTP is a stateless protocol for a reason. Sessions 33 weld state onto HTTP. As a rule of thumb, avoid 32 using session state.

UPDATE: There is no 31 concept of a session at the HTTP level; servers 30 provide this by giving the client a unique 29 ID and telling the client to resubmit it 28 on every request. Then the server uses that 27 ID as a key into a big hashtable of Session 26 objects. Whenever the server gets a request, it 25 looks up the Session info out of its hashtable 24 of session objects based on the ID the client 23 submitted with the request. All this extra 22 work is a double whammy on scalability (a 21 big reason HTTP is stateless).

  • Whammy One: It reduces the work a single server can do.
  • Whammy Two: It makes it harder to scale out because now you can't just route a request to any old server - they don't all have the same session. You can pin all the requests with a given session ID to the same server. That's not easy, and it's a single point of failure (not for the system as a whole, but for big chunks of your users). Or, you could share the session storage across all servers in the cluster, but now you have more complexity: network-attached memory, a stand-alone session server, etc.

Given all 20 that, the more info you put in the session, the 19 bigger the impact on performance (as Vinko 18 points out). Also as Vinko points out, if 17 your object isn't serializable, the session 16 will misbehave. So, as a rule of thumb, avoid 15 putting more than absolutely necessary in 14 the session.

@Vinko You can usually work 13 around having the server store state by 12 embedding the data you're tracking in the 11 response you send back and having the client 10 resubmit it, e.g., sending the data down 9 in a hidden input. If you really need server-side 8 tracking of state, it should probably be 7 in your backing datastore.

(Vinko adds: PHP 6 can use a database for storing session information, and 5 having the client resubmit the data each 4 time might solve potential scalability issues, but 3 opens a big can of security issues you must 2 pay attention to now that the client's in 1 control of all your state)

Score: 20
  • Objects which cannot be serialized (or which contain unserializable members) will not come out of the $_SESSION as you would expect
  • Huge sessions put a burden on the server (serializing and deserializing megs of state each time is expensive)

Other than that I've seen no problems.

0

Score: 11

In my experience, it's generally not worth 6 it for anything more complicated than an 5 StdClass with some properties. The cost 4 of unserializing has always been more than 3 recreating from a database given a session-stored 2 Identifier. It seems cool, but (as always), profiling 1 is the key.

Score: 8

I would suggest don't use state unless you 12 absolutely need it. If you can rebuild the 11 object without using sessions do it. Having 10 states in your webapplication makes the 9 application more complex to build, for every 8 request you have to see what state the user 7 is in. Ofcourse there are times where you 6 cannot avoid using session (example: user 5 have to be kept login during his session 4 on the webapplication). Last I would suggest 3 keeping your session object as small as 2 possible as it impacts performance to serialize 1 and unserialize large objects.

Score: 4

You'll have to remember that resource types 6 (such as db connections or file pointers) wont 5 persist between page loads, and you'll need 4 to invisibly re-create these.

Also consider 3 the size of the session, depending how it 2 is stored, you may have size restrictions, or 1 latency issues.

Score: 1

I would also bring up when upgrading software 24 libraries - we upgraded our software and 23 the old version had objects in session with 22 the V1 software's class names, the new software 21 was crashing when it tried to build the 20 objects that were in the session - as the 19 V2 software didn't use those same classes 18 anymore, it couldn't find them. We had to 17 put in some fix code to detect session objects, delete 16 the session if found, reload the page. The 15 biggest pain initially mind you was recreating 14 this bug when it was first reported (all 13 too familiar, "well, it works for me" :) as 12 it only affected people who where in and 11 out the old and new systems recently - however, good 10 job we did find it before launch as all 9 of our users would surely have had the old 8 session variables in their sessions and 7 would have potentially crashed for all, would 6 have been a terrible launch :)

Anyway, as 5 you suggest in your amendment, I also think 4 it's better to re-create the object. So 3 maybe just storing id and then on each request 2 pulling the object from the database, is 1 better/safer.

More Related questions