As the title says, are there limits (if any) for session variables or they're considered as usual variables and can store equal amount of data?
I'm looking if there are any other limits aside from variable type ones like max length, max values and so on.
P.S. If the question is unclear, please let me know.
Thanks in advance!
This is probably because the register_globals directive is on. It doesn't say it on that page that $_SESSION variables are included, but it says here:
If
register_globalsis enabled, then the global variables and the$_SESSIONentries will automatically reference the same values which were registered in the prior session instance. However, if the variable is registered by$_SESSIONthen the global variable is available since the next request.
If you look closely to my answearin your previous question the very first thing mentioned (written in bold) was exactly this:
Maybe a session is started from a file that is included and this should not happen!
Vineet is correct and I will expand his right answear a bit more!
When you include the file child.php into the father.php you must think of the code found in child.php as being part of father.php One of the first things you do in a father.php script (like index.php) is a session start. You do not start a session in an included script because this might create some conflict as an other session could have been started already.
And if you have many files, (even worse if some of them are both included or executed directly cause of no single entry point) then how easy is to manage all this?!
You said this:
Thanks but the problem doesn't come from the structure of my site
Well this might not be entirely true! The thing is that writing old school code (no mvc, no single entry point, not really object oriented) has the benefit that has a very easy learning curve. HOWEVER while such code is easy to write the thing is that such code requires more skills to avoid errors!
On the other hand the object oriented aproach has more difficulty to get started cause there are more things to learn (objects, prototypes, interface, relatinships (belong-to, is part of) etc etc ) and requires a different behaviour. HOWEVER you definetely will benefit more!
A last thing! Well a well structred-site makes the session manage a thing of a few lines, writen only once at the very begining and that's it all.
I am glad that you are twoards solving you problem!
You will never get unanimous opinion on anything in any large group of people. That's just human nature. Part of that stems from the Dunning-Kruger Effect which states that the less someone knows about a subject, the more likely they are to over value their expertise in that subject. In other words, lots of people think they know something, but only because they don't know they don't know it. Part of it is simply that people have different experiences, and some have found no problems with session, while others have in various situations, or vice versa...
So, to backup your research, which suggest that the answer depends heavily on the requirements, we need to understand what your requirements are. If this is to be a high traffic site, with load balanced servers in a web farm, then stay as far away from session as you can. Sure, it's possible to share session in various ways in a server farm environment (session server, distribute cache server, etc..), but avoiding session will almost always be faster if you can help it.
If your site is a single server, and unlikely to ever grow beyond that. And your traffic patterns are relatively low, then session may be a useful option. However, you should always be aware that session is unreliable storage, and can disappear on you at any time. If the app pool is recycled, session is gone. If an uncaught exception bubbles up to the worker process, the session may be gone. If IIS thinks there's not enough memory, your session may be gone, regardless of any timeout values configured. You also can't always get reliable notification that a session has ended, since terminated sessions do not fire the Session_End event.
Another issue is that Session is serialized. In other words, IIS prevents more than one thread from writing to the session at a time, and it often does this by locking the session while a thread is running if it has not opted out of writable session locking. This can cause severe problems in some cases, and merely poor performance in others. You can mitigate this by marking various methods with a read-only session attribute if you aren't going to be modifying it in that method.
Ultimately, if you do choose to use session, then try to only use it for small, short lived things if at all possible, and if not possible then build in a way to "regenerate" the data if the session is lost. For instance, using your number of items in cart example, you could write a method that first checks to see if the value is there, and if not it goes out and loads it from the database. Always use this method to access the variable, rather than accessing it directly from session... this way, if the session is lost it will just reload it.
However, having said this... For the number of items in a cart, I would generally prefer to use a cookie for this information, since cookies get passed to the page on every load anyways, and this is a small discrete unit of data. Generally prefer Session for sensitive data that you want to prevent the user from being able to change.. number of items in the cart simply doesn't fit that rule.
There's a high likelihood the Qt types distill down to one of the basic types for which numeric_limits are defined. Have you tried calling e.g., std::numeric_limits<qlonglong>::max()?
As MSalters points out, too, if the types are not builtin numeric_limits can still be specialized for them. If that were the case one would hope Qt would include them.
As @Thariama said, there's no limit on the number of variables; also, there's no limit on the amount of data you can store in a session (I've seen sessions tens of MB in size).
As the size of a session gets larger, you'll run into various quirks though: PHP 5 deserializes the whole session into memory at
session_start()(using the default session handler - you can make you own solution, of course); with a 20 MB session and 50 concurrent users, your scripts start to be severely limited by disk access speeds (a.k.a. "script startup is slow as molasses" - the sessions alone would be hogging a GB of RAM); in the end, we dedicated a box to keep as many sessions as possible in its RAM, and the frontend boxes accessed them over NFS (although it helped in our case, this may be overkill for you).Note that for many concurrent users and session storage on disk, the number of session temporary files may cause problems with filesystem limits (e.g. how many files can be in one directory before you run into problems with
stat()performance), or other limits (we once found the hard way that a box was configured to only allow 4096 open files at the same time). None of this is really session-specific, but can be triggered by session handling.