Sign In
Create Account
Follow Us on Twitter
Subscribe on Youtube
1
I assume that, theoretically, several 1000 people could enter their email and press submit on a form at around the same time, so doing a check for entry count in the database may be inaccurate. The check may be untrue, because someone else (user b) could be added to the database after a check (for user count) and before an update (adding user a). I thought of using optimistic locking as a solution. But the way I understand it, with optimistic locking, I may have to display an error if the data was previously updated by another user submission (checking the timestamp). An error message is not very desirable for the end user, so I thought of this pseudocode using the idea of optimistic locking but without an error message everytime the timestamp has changed:
sub adduser(tries) {
if all tries are exhausted {
display error
} else {
check if entries are less than the max defined in the database
if max was reached {
display a message to user informing them no more entries may be submitted
} else {
get current timestamp
...do stuff
check timestamp with one stored in the database
If timestamp was changed by another submission before the update {
call adduser(tries-1) (recursively, to hopefully get a timestamp that is unaltered)
} else {
add user's email to list in db
update timestamp in the database
display a message telling the user that the submission was successful
}
}
}
This is just a basic example I had that I plan to use for different purposes; not just email submissions (I know a lot is missing from the code, but my only concern is keeping the count under control, especially under heavy usage).
Does anyone think this is a solid solution (or that I'm at least on the right track), or is there a better way to deal with this?
Edited by vectorman, 18 February 2011 - 07:36 PM.
Back to top
