Unanswered: Databased session (or cookie) and memory consumption
If I store large text values in session that in turn saves it to a database (save_handler) or cookie, does it affect the memory used by the server? Do the text values stay in server memory (session) along with the database or just the database? In case of storing in cookies, do the text values stay in server memory (cookie) or just the client? I heard we need to be mindful of what we store in session/cookie but could not find enough documentation as for the above.
Cookies - cookies are written to and read from the client when the headers are exchanged at the start of any new/different web page. Any cookies he has that match the current page/domain ... will be read and exist in memory until the current web page is closed. Sorting large amounts of text in a cookie on the client would cause slow exchange of the headers and would slow the loading of the web page.
In your case, with large amounts of data, a cookie should not be used. Using session variables or using your temporary database table would be the best ways.
Sessions - the session ID is typically stored in a cookie and this is how a user is associated with his session. The actual session variables are stored in physical memory for the duration of the current web page/session (from the session_start() or when a variable is 1st created within a session until the web page is closed.) When a page, with an active session, is closed (ie. navigating to another page) the session variables are written to a file on the server and the session is closed. A session_start() on another page will re-open the session for that user (using the session ID/cookie.) You can write the session variables to the file and close the session prior to the end of your script by using a - session_write_close - statement.
The saved session files on the server exist until they are cleaned up. How and when this happens depends on the server file system.
Storing your data in a "temporary" database table would eliminate the saved session files. The data would only exist in physical memory for the duration of any script/web page that is making use of that data. The "temporary" database table would grow and shrink (I'll assume you delete rows from the temporary table after they get added to the main table) as users add/edit records.
Thanks! By default, session vars are written to flat files. As you may be aware, session management in PHP allows us to automatically store vars in a database table instead to get rid of the numerous flat files it writes to the tmp folder by default. I was inquiring if I make the session handler to store session vars in a 'session' table by using session_set_save_handler() would save on memory usage on the server. While the temp table approach of inserting/editing rows and moving them to the main table is completely manual, session_set_save_handler() is automatic in that it stores, retireves, etc. vars from the session table without any manual work. For instance:
There is no special processsing required to use a session table other than configuring the handler to use a session table. Due to this inherent processing, I was wondering if session actually stored all vars in memory while also writing to the session table. I don't wish to choke the server with huge chunks of data if it is going to store it in its memory, too.
Based on my knowledge of this and additional info in the PHP manual for the session_set_save_handler, when an exiting session is re-started, the $_SESSION[...] global array is populated with all the existing variables.
This is supported by the example read function under the session_set_save_handler, where the entire contents of the file is returned. Likewise, the write function writes the entire contents to the file. There is no "element" read or write function. Therefore, when one session variable is read into memory, all of them would be read.
This is also supported by the description for the session_write_close statement. "End the current session and store session data. Session data is usually stored after your script terminated without the need to call session_write_close()..."
Also, this makes sense from a an I/O standpoint. There would be a serious speed penalty if each reference to a session variable resulted in an I/O operation, whether it be for a file operation or a database access (both of which are disk based.)
BTW, if you would choose to use a database to save the session variables, it would be up to you to provide the code for the open, close, read... functions and to call the - session_set_save_handler(...) to "register" the functions.