Question

I’m rather new to working with multiple threads in a database (most of my career has been spent on the frontend).

Today I tried testing out a simple php app I wrote to store values in a mysql db using ISAM tables emulating transactions using Table Locking.

I just wrote a blog post on the procedure Here:

Testing With JMeter

From my results my simple php app appears to keep the transactional integrity intact (as seen from the data in my csv files being the same as the data I re-extracted from the database):

CSV Files:

Query Of Data for Both Users After JMeter Test Run:

Am I right in my assumption that the transactional data integrity is intact?

How do you test for concurrency?

Answer 1

Why not use InnoDB and get the same effect without manual table locks?

Also, what are you protecting against? Consider two users (Bill and Steve):

1. Bill loads record 1234
2. Steve loads record 1234
3. Steve changes record 1234 and submits
4. Bill waits a bit, then updates the stale record 1234 and submits. These changes clobber Bill’s.

Table locking doesn’t offer any higher data integrity than the native MyISAM table locking. MyISAM will natively lock the table files when required to stop data corruption.

In fact, the reason to use InnoDB over MyISAM is that it will do row locking instead of table locking. It also supports transactions. Multiple updates to different records won’t block each other and complex updates to multiple records will block until the transaction is complete.

You need to consider the chance that two updates to the same record will happen at the same time for your application. If it’s likely, table/row locking doesn’t block the second update, it only postpones it until the first update completes.

EDIT

From what I remember, MyISAM has a special behavior for inserts. It doesn’t need to lock the table at all for an insert as it’s just appending to the end of the table. That may not be true for tables with unique indexes or non-autoincrement primary keys.