Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Voting collision #214

Closed
lemming552 opened this Issue · 6 comments

4 participants

@lemming552
Collaborator

If two empires time it so that they both vote at the same instant on a proposition, only one vote gets counted.

@lemming552
Collaborator

Lessened the chance by cleaning out the propositions and votes that had already been dealt with. However, it doesn't remove the chance of a vote collision happening.

@fireartist
Collaborator

I made this suggestion before - though I think it was via in-game mail, so the thread has been long deleted - and I can't remember what response it received.
I really think we should be doing calculations such as this within the database - e.g. 'UPDATE propositions SET votes_yes = votes_yes + 1 where id = ?'.
I can't remember how elegantly DBIx::Class handles this - it may require manually refreshing the row values from the db, so the new values can be used in the server response.
It might be worthwhile trying it out in a small area such as voting, though - and see how it goes?

@icydee
Owner
@lemming552
Collaborator

It had happened at least once.. I believe it occurred because an alliance runs their voting script where the script fired off all members at the same time. And as it was, they were just one vote short but I was able to confirm that ten empires had voted, yet only nine votes had been counted.

-norway

@dmcbride
Collaborator

That would have been Anarchy!, where I fired off the GLC "parliament.pl" script for every participating ally simultaneously. I've more or less eliminated the issue on my end by waiting a few seconds (10 or 15 seconds, I think) between launches, and by getting more sitter pw's so that even one vote being miscounted wouldn't prevent us from passing anything. But at the time, we had at least two or three propositions hanging, waiting for the missing vote.

As for the SQL statement, I'm pretty sure fireartist's statement is atomic. The DB is responsible for gaining the locks required.

While the auto-vote being discussed would obviate the need for this from our end, I'm not sure this is the only place in the code where values are read, updated, and put back in the database allowing some other process to go in and write the same rows in between.

@lemming552
Collaborator

Hey look at this, still a problem. :) Clearing the propositions DB of all passed props actually solves this, and a simple clean script could deal with this weekly. (At least until we clean up the how SS work...)

@dmcbride dmcbride closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.