what to do with concurrency-risky tasks? - mysql

Question

I'm looking for a solution for this:
function foo()
{
client 1 executes an update/delete
// client 2 calls foo() and breaks data integrity
client 1 executes an update/delete
}
how do I solve this with mysql? I'm using myisam tables but I'm interested to the innoDB solution as well

Answer 1

Note: This answer assumes that you are InnoDB which allows row level locking instead of MyISAM which requires table locks.
For cases like this, you would use transactions and READ/WRITE locks. The exact details of which you need vary from case to case, and I cannot answer that without knowing you schema and what data integrity you are worried about, so I will give you a general explanation.
A read lock can be acquired on rows which you do not intend to write to, but mustn't change for the duration of your transaction. A write lock can be acquired on rows which you intend to change at some point in the future. A transaction is a sequence of multiple actions which are applied in an all-or-nothing way to the database.
So as an example lets suppose the following:
you have 3 tables: table_A, table_B, table_C
The operation which client 1 is performing makes an update to table_A and then to
table_B.
Client 2 could be updating table any of the tables.
You require some data consistency between all 3 tables.
You would do something like this:
// This makes it so that each operation is not automatically commited (saved)
// It implicitly makes all sequences of operations into transactions
execute("set autocommit=0");
// This gets you some data from table_B and also gets a read lock to prevent that data from changing
result = execute("SELECT * FROM `table_B` WHERE `condition` = 1 LOCK IN SHARE MODE");
// This gets some data from table_C and gets a write lock to prevent the data from changing and allowing you to write to it in the future
result2 = execute("SELECT * FROM `table_C` WHERE `condition` = 1 FOR UPDATE");
// This performs your update to table_A
execute("UPDATE `table_A` SET `value` = 1234 WHERE `condition` = 1");
// This performs your update to table_C
execute("UPDATE `table_C` SET `value` = 4321 WHERE `condition` = 1");
// This saves all of the changes that you made during your transaction and releases all locks
// Note: autocommit is still turned off
execute("COMMIT");
So lets have a more concrete example involving purchasing something. I realize that this could all be done by a single update statement but I am doing it this way to illustrate how to use transactions.
My tables are:
items (id int not null primary key, user_id int not null, item_type int not null)
accounts (user_id int not null primary key, balance int not null)
prices (item_type int not null primary key, price int not null)
limits (item_type int not null primary key, max_count int not null)
Note I am going to skip input sanitation for brevity sake, DO NOT do that for real. (http://xkcd.com/327/)
function purchase(user_id, item_type) {
execute("set autocommit=0");
// I am assuming that price and max_count can be changed but they require consistency with each other hence the read locks
var price = execute("SELECT `price` FROM `prices` WHERE `item_type` = " + item_type + " LOCK IN SHARE MODE")[0].price;
var max_count = execute("SELECT `max_count` FROM `limits` WHERE `item_type` = " + item_type + " LOCK IN SHARE MODE")[0].max_count;
// I need the write lock to prevent double spending
var account = execute("SELECT * FROM `accounts` WHERE `user_id` = " + user_id + " FOR UPDATE")[0];
// I need to guarantee that the user is not over the limit
var count = execute("SELECT count(*) AS `count` FROM `items` WHERE `user_id` = " + user_id + " FOR UPDATE")[0].count;
var new_balance = account.balance - price;
if(count >= max_count || new_balance < 0) {
return false;
}
execute("INSERT INTO `items` (`user_id`, `item_type`) VALUES (" + user_id + ", " + item_type + ")");
execute("UPDATE `accounts` SET `balance` = " + new_balance + " WHERE `user_id` = " + user_id);
execute("COMMIT");
return true;
}
Also it should be noted that you now have to worry about deadlocks, but that is an entirely separate topic.