Testing Concurrency

Kendra Little walks through using OStress to test concurrency:

Even though I’m taking out UPDLOCKS, the following race condition pattern can still occur

  • Session A takes out an UPDLOCK, sees that key 266 does not exist, releases its UPDLOCK, and prepares to insert
  • Session B takes out an UPDLOCK, sees that key 266 does not exist, releases its UPDLOCK, and prepares to insert
  • Session A runs its  insert
  • Session B attempts to run its insert, but fails because of a duplicate key error

We need to hold that lock.

Understanding concurrency is one of the toughest parts of being a database developer, especially because it’s historically been difficult to test it.  I like what Kendra’s done here, making the process easy to follow.

Related Posts

Natural Keys?

Steve Jones wonders if we should give up on natural primary key constraints: One of the things I think is important in modeling your particular entity is including a primary key (PK). In my DevOps talk I stress this, as I’d rather most attendees come away thinking a PK is important as their first takeaway […]

Read More

Range Locks On Multi-Table Indexed Views

Erik Darling looks at the kinds of locks taken when updating an indexed view: So what causes Range Locks? Just ask Sunil. He knows everything (this assumes the serializable isolation level): Equality Predicate If the key value exists, then the range lock is only taken if the index is non-unique. In the non-unique index case, the […]

Read More

Categories

June 2016
MTWTFSS
« May Jul »
 12345
6789101112
13141516171819
20212223242526
27282930