Comments on: READ-COMMITED vs REPETABLE-READ in tpcc-like load

By: VJ Kumar

VJ Kumar — Sun, 21 Feb 2010 18:34:23 +0000

I am not sure why there should be any difference in locking or dead-locking between RC and RR at all.

I am not familiar with InnoDB internals, but assuming it implements traditional multi-versioning of the Oracle flavour, there should not be any locking while providing read consistency. E.g. in Oracle, the only difference between the case when you have statement-level read consistency and the case when you want to ensure transaction level read consistency is how far back in time, or to what specific version of the row, you want to go: to the beginning of the statement or to the beginning of the entire transaction.

What am I missing ? I am sure for an InnoDB expert it should be easy to create a deterministic test case and demonstrate why there is more locking (or any locking at all) with RR vs. RC.

By: Jay Paroline

Jay Paroline — Tue, 16 Feb 2010 18:50:21 +0000

We switched from REPEATABLE-READ to READ-COMMITTED because we were getting lots and lots of deadlocks all of the time. Deadlocks have pretty much gone away completely since switching to READ-COMMITTED, which seems to be in direct contradiction with your statement. Why would that be? We are using MySQL 5.0.

By: Arjen Lentz

Arjen Lentz — Sun, 14 Feb 2010 23:57:34 +0000

I thought this was old news, but good to see it proven in practice. The way I learnt about it long ago is that given InnoDB’s architecture, there’s no advantage to lowering the isolation level. The amount of ‘housekeeping’ internally (aka overhead) is virtually the same between REPEATABLE READ and READ COMMITTED.

By: tobi

tobi — Sat, 13 Feb 2010 14:03:19 +0000

very interesing results, never seen a benchmark quantify the cost of isolation levels. please also provide comparisions for all other levels.

By: Kim

Kim — Fri, 12 Feb 2010 08:30:30 +0000

For some time we have used Read-Committed and has encountered alot of weird bugs with this isolation level, it seems
that everytime the mysql team made a new feature, it wasnt tested as well with read-committed isolation level as the commonly used repeatable-read.

We have now changed isolation level to default(repeatable read). This has resulted in noticeable more deadlocks than read-committed, and so far less
bugs.

To me it seems strange that repeatable-read gives less deadlocks compared to read-committed as it is a higher isolation level and therefore must lock more.

By: Aurimas Mikalauskas

Aurimas Mikalauskas — Thu, 11 Feb 2010 07:00:01 +0000

VJ Kumar, in one case I was just working on we had two transactions deleting rows using secondary key and then inserting new records with same secondary key values. By switching to read-committed we were able to avoid deadlocks because InnoDB would lock a gap after the delete in repeatable-read. In RC InnoDB almost never uses a gap locking which is a common reason for deadlocks in RR.