Home/ Questions/Q 4013850
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T09:25:23+00:00

Right now I’m stuck between using PHP’s native session management, or creating my own

  • 0

Right now I’m stuck between using PHP’s native session management, or creating my own (MySQL-based) session system, and I have a few questions regarding both.

  1. Other than session fixation and session hijacking, what other concerns are there with using PHP’s native session handling code? Both of these have easy fixes, but yet I keep seeing people writing their own systems to handle sessions so I’m wondering why.

  2. Would a MySQL-based session handler be faster than PHP’s native sessions? Assuming a standard (Not ‘memory’) table.

  3. Are there any major downsides to using session_set_save_handler? I can make it fit my standards for the most part (Other than naming). Plus I personally like the idea of using $_SESSION['blah'] = 'blah' vs $session->assign('blah', 'blah'), or something to that extent.

  4. Are there any good php session resources out there that I should take a look at? The last time I worked with sessions was 10 years ago, so my knowledge is a little stagnant. Google and Stackoverflow searches yield a lot of basic, obviously poorly written tutorials and examples (Store username + md5(password) in a cookie then create a session!), so I’m hoping someone here has some legitimate, higher-brow resources.

  5. Regardless of my choice, I will be forcing a cookie-only approach. Is this wrong in any way? The sites that this code will power have average users, in an average security environment. I remember this being a huge problem the last time I used sessions, but the idea of using in-url sessions makes me extremely nervous.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The answer to 2) is – id depends.
    Let me explain: in order for the session handler to function properly you really should implement some type of lock and unlock mechanism. MySQL conveniently have the functions to lock table and unclock table. If you don’t implement table locking in session handler then you risk having race conditions in ajax-based requests. Believe me, you don’t want those.

    Read this detailed article that explains race condition in custom session handler :

    Ok then, if you add LOCK TABLE and UNLOCK TABLE to every session call like you should, then the your custom session handler will become a bit slower.

    One thing you can do to make it much faster is to use HEAP table to store session. That means data will be stored in RAM only and never written to disk. This will work blindingly fast but if server goes down, all session data is lost.

    If you OK with that possibility of session being lost when server goes down, then you should instead use memcache as session handler. Memcache already has all necessary functions to be used a php session handler, all you need to do it install memcache server, install php’s memcache extension and then add something like this to you php.ini

    [Session]
; Handler used to store/retrieve data.
; http://php.net/session.save-handler
;session.save_handler = files
session.save_handler = memcache
session.save_path="tcp://127.0.0.1:11215?persistent=1"

    This will definetely be much faster than default file based session handler

    The advantages of using MySQL as session handler is that you can write custom class that does other things, extra things when data is saved to session. For example, let’s say you save an object the represents the USER into session. You can have a custom session handler to extract username, userid, avatar from that OBJECT and write them to MySQL SESSION table into their own dedicated columns, making it possible to easily show Who’s online

    If you don’t need extra methods in your session handler then there is no reason to use MySQL to store session data

    • 0