tags:

views:

47

answers:

2

Hypothetically, if the user clicks "save,save,save,save" a bunch of times on a text file, making single character changes at a time and managing to resave 5 times before the first save is processed, what is best practice in that situation? Assuming we don't have a "batch process" option... Or maybe they push save,save,save,save on 4 files one after the next before they've all been processed.

Should you queue up the requests and process them one at a time? Or should you just let it happen and it will work itself out somehow?

Thanks!

+2  A: 

We usually send down a GUID in the page when a form is initialized, and send it along on the save request. The server checks a shared short-term memory cache- if it's a miss, we store the GUID and process the save, if it's a hit, we fail as a dupe request. This allows one save per page load (unless you do something to reinit the GUID on a successful save).

nitzmahone
i'm just wondering if it's a problem for the server, or does it have everything built in to handle this? I'm thinking Rails here :)
viatropos
Just depends on the editing semantics. If "last writer wins" is OK and you don't have any app-level transaction or locking issues, I wouldn't worry about it. If you're talking about credit card transactions or something else with major side effects (save-to-disk, file creation, etc), then yeah, you need to lock it down somehow.
nitzmahone
+2  A: 

If you make your save operation light enough, it shouldn't matter how many times the user hits save. The amount of traffic a single user can generate is usually quite light compared to the load of thousands of users.

I'd suggest watching the HTTP traffic when you compose a Gmail message or work in Google docs. Both are very chatty, and frequently send updates back to the server.

brianegge