Voting collision

[lemming552]

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

[lemming552]

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]

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]

I'm not sure if an UPDATE as described is atomic, to be certain we would
need to do it in a transaction, but we don't do any transactions in TLE.

In any case the chance of a collision is so small that I would be surprised
if it has actually ever happened.

• icydee

On 5 March 2013 09:28, fireartist notifications@github.com wrote:

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?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/214#issuecomment-14430807
.

Kind Regards
Iain

[lemming552]

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]

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]

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...)