dunc4n;10994680 wrote:
So if the sessionHandler class doesn't hide all the session data from the cookie I am still at a loss as to what it does exactly
It can in reality do anything. If you look at [man]session_set_save_handler[/man] you see that there are two ways of using it. One is by using 6 functions for handling sessions, the other is by using a class which contains the corresponding 6 functions. For example, SessionHander::open() or the corresponding callback function open() are called when you call session_start() if you use custom session handling. Otherwise php uses its default session functionality, which is storing things on disk.
But what these things do? Well, that is entirely up to you since you'd be writing the code to replace the session handling (if you find a need for it). You might delete a random file from disk every time session_start() is called... Not useful or sensible, but it's your code.
dunc4n;10994680 wrote:
or is it more of an ability to store session history on a table.
If by table you mean db table, that is one possible way of handling sessions. Instead of storing them on disk you could move them to a database. That way, you might easily keep searchable session history if that's of any use.
dunc4n;10994680 wrote:
If the data stored isn't accessible to the user as is than it seems like storing session info in a database would be additional,
Yes, unless you have specific reasons for wanting to store sessions in a db, I'd just leave PHP's custom session handling in place. On the other hand, if you don't understand how sessions work, perhaps it would be a good exercise to implement db session storage. Once done with that you should have a good grasp on how sessions work, and then you can go back to PHP's default handling.
dunc4n;10994680 wrote:
and unnecessary server calls increasing the bandwidth.
I'm assuming you mean bandwith usage. Still, it depends. If the same machine runs both the webserver and the DBMS and you are not connecting to the DBMS over TCP/IP but rather use named pipes or sockets, then there will be no increase in bandwith usage. And even using the localhost loopback ther would be no network traffic actually leaving the machine, i.e. you wouldn't be using the bandwith you pay your ISP for.
Also, since you have to connect to the DBMS anyway, this query really will not matter. The lookup and data retrieval should be compareable to PHP's time needed to lookup and retrieve the session data from disk. Moreover, unless the db session table data and PHP's session data files are stored in ram, most of the time is likely to be spent on HDD seek-time and rotational latency, which would be roughly from 3ms+3ms to 6ms+6ms for a traditional HDD while a SDD would require 0.2-1ms for seektime and have no rotational latency.
Thus, if session data isn't kept in ram, there will be no point in choosing one over the other for speed purposes. And even in RAM I'd say you can forget about it.
The only other factor I can think of would be if the webserve and DBMS are located far away from each other since it takes time for information to be transfered as well.
