views:

47

answers:

3

i'm planning on making my own custom session handling functions. i want to save it in the database but i have some doubts.

  • is it viable or will just slow down my app?

  • i have to save the session after each set or can i just save it all at once? because i had this idea to put this function in the class destructor method. so, when the program ends, it will save the data in the database.

    • but how can i use my other class (database class) for this, being sure it won't be destructed before the session class?

    • if the user quits the connection and the app stops running, the destructor will still be called?

so, what do you guys think? what do you suggest me to do?

+1  A: 

I use DB sessions all the time with Zend and Symfony so its definitely viable, there will be a cost of course but most likely nothing significant.

Normally the way these handlers work is to use session_set_save_handler that way it works as normal except for the actual function called which writes the data. However pay attention to the warnings about object destruction.

prodigitalson
A: 

Yes it will normally be slightly slower than PHP's native session handler, however it shouldn't be noticeable. This is unless you are having problems with file locking issues (like Windows does)

Petah
A: 

Why would you want to permanently store session data? Usually people use different session handlers to make application faster (we use memcache for sessions, because our application is quite complex and distributed and we want it to run fast). I consider this requirement as bad application design, if you want to track your visitors in some way, there are a lot of better ways doing it. Or you are using session for the things it is not quite intended/suitable for. Of course i can imagine that there might be that kind of requirement, just i dont think that this is the case.

nimmen
It doesnt have anything to do with keeping historical session data. Normally its about having access to the same session data across multiple instances of an application in a distributed, scaled or load balanced deployment. IT essentially the same thing you are doing with memcache, albeit slower and easier to set up and manage.
prodigitalson