Tomorrow night, March 15, I will be at the Hampton Roads SQL Server User Group’s March meeting, then at SQL Saturday Richmond on Saturday the 19th, then finally back at home on the 25th for my home user group in Nashville (which I haven’t seen much of this year) to present a presentation that I am pretty fond of after having done it once before in Nashville, and 20 times for myself.

Here is the abstract:

Let Me Finish… Isolating Write Operations

OLTP databases can be constantly written to and reporting databases are written to at least periodically. In order to ensure consistent results, connections must be isolated from one another while executing, ideally with the lowest possible cost to concurrency.  How this isolation is handled is based on the isolation level, whether the classic lock based or the newer optimistic scheme of the in-memory OLTP engine is used, or even if both engines are enlisted in the same transaction. In this session we will look at examples of how SQL Server isolates reading and writing operations from other writing operations to explore how this may affect your application through error messages and performance hits.

What I like about it is that it takes the “fun” parts (okay, technical and nerdy parts) of my In-Memory DB Design session I had done several times last year (until SQL Server 2016 changed it beyond recognition) and makes it more applicable to more people. I cover the locking and optimistic concurrency controls that are in SQL Server 2016, and since RC0 has just arrived, I get to do it on what might be the release version of SQL Server.

Hope to see you at one of these (and if not, I am scheduled to do this presentation again for Pensacola’s SQL Saturday in June).