Question : Trouble With High Volume Select Statments

I have written a custom php session handler which uses the default session id's but stores the session information in a MySQL database. The site running the manager handles roughly 30k visitors a day, each of which generate roughly 5 session writes and lookups in very rapid succession due to AJAX requests. The same issue has arisen using MS SQL Server as a storage platform. The problem occurs on session writes. The write function first tries to locate an existing entry in the session table with the session id (used as the primary key) and then either inserts or updates the record accordingly. Occasionally (1%-5% of session writes) the initial lookup comes back empty even though the session is not new, and there is a row in the database attached to the session id. The logic then tries to insert a new record, only to run afoul of primary key uniqueness constraint. This causes unacceptable failure. The failure is handled relatively gracefully, but provides a significantly degraded user experience. After many attempts to resolve the issue, I have been unsuccessful. The table is using InnoDB as an engine and utf8_general_ci as a character set. The web app is running on Zend Framework and using the framework's DB functionality. The problem still occurs when reglar mysqli connections are employed instead. Any insight would be greatly appreciated. Psuedo code for the session write is provided below.

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
function sessionWrite( id, sessionData )
    sql = 'select 1 from sessions where sessionId = id';
    rows = db->query(sql); // occasionally comes back with 
                           // null result set even though
                           // session record exists
    if( count(rows) > 0 )
        updateRecord(id,sessionData);
    else
        // Then tries to insert duplicate row
        insertNewRecord(id,sessionData);
    return;

Answer : Trouble With High Volume Select Statments

1 - When handling yourself the update with SQL queries, test the impact of
INSERT * ON DUPLICATE KEY UPDATE *

cf http://dev.mysql.com/doc/refman/5.0/fr/insert.html

2 - Since you are handling in parallel $_SESSION and sql copies of session data, you might consider storing the sql id into the $_SESSION data
When are you doing the first write/ insert?
In some cases $_SESSION is updated only after the page is left...

3 - It seems you are really playing in a dangerous area where precise timing is not really guaranteed and where you should therefore expect lots of troubles.
I would try to reconsider and update session data only on some significant events, so that any cached SQL query has had some time to execute. Your system would then be more robust, and the load on the server would also drop significantly.
Or have some $_SESSION holding the timestamp of the last update and updating only after 2 seconds
Sure, not very Ajax-like but hey, this depends on your SQL server and the stress you put on it. Microseconds or even milli- or centi-seconds updates are fine for Ajax, but not for SQL server