![]() ![]() In InnoDB Data Locking – Part 1 “Introduction” we’ve seen a simple example of scenario in which two people can not finish what they’ve started, because one is waiting for the other to release a resource which is currently in use by the other and vice-versa: ABe already had Read access to file A and requested Write access to file B, but had to wait for BAsil to first release his Read access rights for this file, however BAsil can not do that until he finishes what he planned, which was to obtain Write access to file A, currently in use by ABe. Summary of this post: In this post I’ll describe how deadlock detection works in InnoDB 8.0.18, and thus introduce following concepts : deadlocks caused by granularity, and ways to overcome them by lock ordering.granularity of a lock (access right to everything vs.read views (read-only snapshots which allow stale reads concurrent to new writes).starvation (permanent inflow of readers starving a writer waiting for its turn).reader-writer lock (shared/exclusive access rights).timeouts (for misbehaving lock owners, and to resolve deadlocks).serializability of transactions (ability to explain states observed over time with a convincing story about relative order of parallel operations).databases, tables, rows (like files on a shared drive, spreadsheets inside a file, and rows inside a spreadsheet).In InnoDB Data Locking – Part 1 “Introduction” I’ve introduced basic concepts required to understand current post: In this blog series, I’m describing how InnoDB locks data (tables and rows) in order to provide illusion to clients that their queries are executed one after another, and how this was improved in recent releases.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |