I'm using a SESSION variable to set the pre-allocated record id from Postgres (getting the record id sequence) using PEAR's DB nextId(). I set the I id to a session variable because of scoping issues in the legacy code I'm working with. After the INSERT happens I use the unset() to remove the SESSION variable (This is to clear the used record id). There is more information in the session as well that remains intact, it's just the next_id element that is being removed.
Pseudo code:
// Get the next Id and set to SESSION
$_SESSION['next_id'] = $db->nextId();
... more code here
// After insert
unset($_SESSION['next_id']);
My question is, Would clicking the back button on the browser somehow reset the SESSION variable $_SESSION['next_id']? Maybe causing it to be NULL? How does CACHE handle the SESSION after an element has been removed but the user has returned to a previous state?
EDIT: the reason for the question is that the code in production is randomly (by any user) trying to INSERT with a NULL record id (Which is the next_id from SESSION). Just trying to debug the process as the code is very minimal, reviewed by my peers and has just stumped us???
EDIT 2: Wow I guess there is an issue with how I'm using the SESSION variable. Well I'll explain as much as I can as to why I chose this method. First the code is in the process on being rewritten from PHP 4, but the current production version is mostly PHP 4 with a ton a newly added module code in PHP 5. The reason I chose the SESSION variable is because of a scoping issue that would need to be hard coded on several hundred pages of legacy code or on one page and cast the value into the SESSION which all pages have access to. (well my boss who pays my salary like the option I chose). The original problem is they (my boss) wanted to display the id to the end user before the insertion of the information. Hence the PEAR DB call nextId(). We use PostgreSQL and I'm using the record id sequence to ensure that the next id will be unique and allocated to the end user only (No duplicates as Postgres handles locking this in the sequence). So the end user can also navigate to multiple pages during the process, this also is another scoping issue. Now using the SESSION and retrieving the next Id with some validation and checks is about 50 lines of code for the whole process instead of the thousands of lines of code that would have been written to do this the correct way. Again NOT MY CODE in the first place, just making the best solution at the least possible cost.
If you have another, better, greater, easier, cheaper solution feel free to post away. But if you're going to piss on my decision about how to code, then please pay my bills and I will fully agree with following better coding standard,practices,solution.
Found the cause of the issue. End users are opening multiple tabs in their browsers causing the SESSION data to span to any open tab as they all would call the same session. So submitting one request in one tab, unsets the session in all tabs. So when they submit the request in the second tab the session is missing the next_id value causing all the problems. User training will solve the issue for now but looking to implement things in a new way soon.
Thanks for all the efforts