One solution is to use the same strategy that we used in Customizing Content for Users and Devices—that is, store only the user's ID in a cookie and keep track of his three last searches in a database. Any database worth its salt will make sure that one request is finished altering a row before the next one is allowed to start.
Even here, there is room for error. Suppose your program does something like this:
Step 1: SELECT search1, search2, search3 FROM searchtable WHERE userid=$cookie_userid;
Step 2: (code to set $newsearch3=search2, $newsearch2=search1, $newsearch1=$new_search_string)
Step 3: UPDATE searchtable SET search1=$newsearch1, search2=$newsearch2, search3=$newsearch3 WHERE userid=$cookie_userid;
You can run into problems if a concurrently running program executes an UPDATE while you are busy running step 2. You will probably want to insert a LOCK statement before step 1, and an UNLOCK statement after step 3, to prevent other programs from reading that row until you are finished altering it.
| Send feedback about this page using email. | Copyright © 2008, iAnywhere Solutions, Inc. |