Preventing a site-wide double submit

Question

I was having a hard time figuring out a good title for this question, so I hope this is clear. I am currently using the TwitterOauth module on one of my sites to post a tweet. While this works, I need to set a limit to the amount of tweets submitted; just one each hour .

Note: I do not have the option to use a database. This is paramount for the question.

I have incorporated this as follows, in the PHP file that handles the actual posting to the Twitter API:

# Save the timestamp, make sure lastSentTweet exists and is writeable
function saveTimestamp(){
    $myFile = "./lastSentTweet.inc";
    $fh = fopen($myFile, 'w');
    $stringData = '<?php function getLastTweetTimestamp() { return '.time().';}';
    fwrite($fh, $stringData);
    fclose($fh);
}

# Include the lastSentTweet time
include('./lastSentTweet.inc');

# Define the delay
define('TWEET_DELAY', 3600);

# Check for the last tweet
if (time() > getLastTweetTimestamp() + TWEET_DELAY) {
    // Posting to Twitter API here
} else {
    die("No.");
}

(initial) contents of the lastSentTweet.inc file (chmod 777):

<?php function getLastTweetTimestamp() { return 1344362207;}

The problem is that while this works; it allows for accidental double submits; if multiple users (and the site this script runs on is currently extremely busy) trigger this script, it happens that 2 submits (or more, though this has not occurred yet) to Twitter slip through, instead of just the 1. My first thought is the (although minute) delay in opening, writing and closing the file, but I could be wrong.

Does anyone have an idea what allows for the accidental double submits (and how to fix this)?

Answer 1

You're getting race conditions. You will need to implement locking on your file while you're making changes, but you need to enclose both the read (the include statement) and the update inside the lock; what is critical is to ensure nobody else (eg another HTTP request) is using the file, while you read its current value and then update it with the new timestamp.

This would be fairly ineffective. You have other options which might be available in your PHP installation, here are some:

1. You can use a database even if you don't have a database server: SQLite
2. You can store your timestamp in APC and use apc_cas() to detect if your last stored timestamp is still current when you update it.

Update

Your locking workflow needs to be something like this:

1. Acquire the lock on your stored timestamp. If you're working with files, you need to have the file open for reading and writing, and have called flock() on it. flock() will hang if another process has the file locked, and will return only after it has acquired the lock, at which point other processes attempting to lock the file will hang.
2. Read the stored timestamp from the already locked file.
3. Check if the required time has passed since the stored timestamp.
   • Only if it has passed, send the tweet and save the current timestamp to the file; otherwise you don't touch the stored timestamp.
4. Release the lock (just closing the file is enough).

This would ensure that no other process would update the timestamp after you have read and tested it but before you have stored the new timestamp.