Is it bad to use the standard PHP session engine?

Question

What I understand is that many frameworks, like Codeigniter and Laravel 3 and 4 use their own session storage engine. They don’t use the standard PHP engine (Variable $_SESSION and session_start, among other things).

And when I say "own mechanism" I’m not talking about changing the behavior of the PHP session with the interface SessionHandler or session_set_save_handler, but I am talking about working with a mechanism for creating the session, without using any of the (ready) PHP resources.

I wonder if there is something bad with the standard PHP session engine?

There is some limitation in the native PHP session, so that the frameworks use another way to implement sessions?

Answer 1

As every resource you need to understand it completely, read all documentation and eventually look for undocumented information. Something complex like this can have a lot of details that can go unnoticed. I will not try to put everything that needs to be checked, not least because I am not an expert on the subject, and I do not think it fits, my intention is not to give a definitive answer.

The main reason for frameworks providing mechanisms for any technology is the abstraction of the resource.

Abstraction is one of the most misunderstood concepts in computing. It has always existed before modern computers even existed. Abstraction gives more meaning to what is being done and puts a layer on top of the concrete, allowing the actual implementation to be hidden from the user of that resource.

One of the biggest advantages of abstraction is that if it is done well it can change the implementation without requiring the codes that use it to be modified. This is very important in several scenarios. It is not always possible to do well, no matter how good the programmer. And not always the complication of abstraction that will be necessary is worth the effort.

So it’s interesting that these products have a shape that at least does not depend on the PHP standard.

And since the standard has a relatively simple and fixed implementation it is natural that they provide a more powerful and flexible implementation. I can imagine a lot of things that are possible to do in a session beyond what the standard implementation provides. There are several scenarios where the pattern does not meet well. Although most scenarios dispense with any other solution.

In addition to obviously supplying more information, better integration with database and session distribution and transportation and otherwise identifying information and active session count are some examples of what can be improved.

As stated in the comments, the fact of creating a version of its own does not mean that it will get better. Although the intention of these frameworks is to facilitate the use of resources compared to what exists in PHP. Perhaps the attempt to do something better has left too complex.

Most of the problems I see with using the standard session have to do with misuse. Okay, it might be a little difficult to get it right, but it’s the programmer’s obligation to know how to do this. And the frameworks will have to choose between facilitating or giving a more powerful and flexible resource. What I see them doing a lot is applying such good practices, that is, they choose what is good for you, even if that is not the best ever.

By the size of documentation page of only one function gives you an idea of how difficult it is to use right, safely, but it doesn’t have much to do when the problem is complex (although it’s an exaggeration to call it complex).

I wonder if there is something bad with the standard PHP session engine?

If it was so problematic it would already have enough recommendation not to use, someone would have already made a replacement in PHP. It’s good to have some information here, but the problem isn’t in the resource, it’s in the little piece between the keyboard and the chair :)

Answer 2

It depends. The use of Sessions PHP default does not present problems in general, however it can be bad depending on how it is used. The save Handler pattern uses files, so in each request received, even with you not using the session in some, will roll a lock in the session files and a subsequent reading of them, this may represent a overhead relevant if you have a really great amount of requests.

Another detail is that, as I said, make a request generates a lock in your session file (whose default path is something like /var/lib/php/session/sess_$identifier), therefore any requests competitors have to wait for the release of this lock so that they can proceed. The lock starts in session_start() and ends at the end of the execution of your script, or on the call from session_write_close(), this way in case you have a situation where the client does several AJAX requests followed to the server all these requests queue up waiting for what arrived before releasing the session file lock, and that’s really bad. The ideal to minimize this problem is always use session_write_close() as close as possible to the start of the session, otherwise requests competitors will have to wait until the end of the execution of script arrived first, which can mean a hit of operation (read files, access database, process things, etc).

Another problem that seems to take several frameworks to avoid the use of Sessions PHP default is the fact that session_start(), as soon as invoked, always send the cookie session for the client. The problem here is related to the one described in the previous paragraph, you want to close the session as soon as possible after opening it, however you may want to do something like write something in the session at the end of your PHP script and if it has already closed it will need to reopen. In this situation you have the problem that you will probably receive an error similar to Headers already sent because in HTTP the header is always sent before the content, and at a late stage of its script it is likely that you have already finished sending the header and started sending content and calling session_start() will try to send more header (the cookie).

Finally we have the question already commented on in Maniero’s answer, which although so abstract that you use it in 90% of conceptual programming questions (hah is zoeira in, the answer is good ;) ), explains well the fact that you often want a control greater than that given by a native implementation, or want to have an access to a different abstraction, or want something more flexible, or still want an implementation whose operation is easier to understand (that knowing what goes on underneath the cloths, without "magic").