Web game concurrency control

There are some other SO questions about concurrency but they don't quite address my scenario.

So let's say that I have a game where users interact with each other, fighting and whatnot. At any given time, a player could potentially be involved in multiple interactions with other players, all of whom can see the event happening. When any one of these players hits the site, i开发者_C百科t needs to update any data involved and show that to the user.

Example situation: Player A is fighting with player B, and events happen every few minutes in this fight. At the same time, player A is also interacting with player C. By dumb luck, the events for both interactions happen to next be due at the exact same second.

When that second arrives, by dumb luck again, both player B and player C hit the site at the same time, in order to check the status of their fights with player A. Fighting requires updates to information about player A. If I don't code properly, A's data can get messed up.

I have two games with this situation, each with a different solution and different issues. One of them uses a lock, so when a user hits the site, they acquire a lock on a db row, read the data for locks they successfully acquired, then write the changes and release the lock. But sometimes, for reasons still unknown, this fails and the lock gets stuck forever, users complain and we have to fix it manually. My other game uses a daemon to execute these transactions, making the issue (nearly) moot as there is only one process ever making these changes. But players could still do other things at the same time, and potentially cause the same issue.

I've read a bit about different solutions to this, like optimistic or timestamp-based control. I would like to ask:

1. Which of these is most commonly used for situations like mine, and which is easiest to implement?

2. My next project is using Kohana (PHP) and its ORM, so my db writes will by default take the form "just overwrite all these fields." Will I need to write my own update queries for this or can I get a solution that is compatible with the ORM?

3. What about transactions that involve multiple tables? The outcome of a combat has to change the table of combats, and the table of player information, possibly more things too. Which solutions are easier to work with here? Will all of my tables need transaction timestamp columns?

4. A lot of these solutions say that when there is a conflict, either retry or ignore. What does this mean for me? Does "retry" mean restart my entire script, which would cause additional load time for the user? I don't think ignore is a valid option, since the events have to execute at some point. In the other questions I found, presenting a conflict error to the user was usually a valid option - for me, it isn't.

5. What are the performance implications of concurrency control - is it even worth it?

---

I think what you are looking for is already contained in your question : transactions. If you are using MySQL, you will need to setup your tables with the innoDb engine to be able to use transactions. Some documentation :

• http://dev.mysql.com/doc/refman/5.1/en/commit.html
• http://www.php.net/manual/en/pdo.begintransaction.php
• http://www.php.net/manual/en/mysqli.autocommit.php

Don't try to reinvent the wheel when you can.