Re: Making credit processing atomic

Here is what I do:

Generate a unique key. (This is just be a large random #)
Store the unique key in the submit form.
Insert your data into the database with then Unique key being stored in a unique field.
Now if the user submits twice (or 100 times) only one of the inserts will succeed.

This can fail if you are pick a random number that is already in the database (or you can check that) and it will fail if 2 user get the same unique key. You can't protect against this, but the odds are 1 in 4*10^9 if you use on a 32 bit key, but if you use a 64 bit key, then key collition is not be a problem at all.

-- gam3
A picture is worth a thousand words, but takes 200K.

Comment on Re: Making credit processing atomic

Replies are listed 'Best First'.
Re^2: Making credit processing atomic by satchm0h (Beadle) on Apr 12, 2005 at 22:21 UTC
Check out Data::UUID for your unique identifyers. Stop worrying about collisions, unless of course you have dynamic MACs or are prone to backward time warps. satchm0h...stumbling down the path toward enlightenment	[reply]