The CAP theorem remains one of the most important tools in my software developer's toolbelt. Used correctly, it can help create services and products that can offer an excellent user experience and protect revenue during partial failures. Used incorrectly, it can lead to a poor user experience and loss of revenue. Throughout this article, I look to explain the unexpected latency of specific transactions in MySQL, a CP system.

Despite the fact I've been developing software in one way or another for almost 20 years, I'm constantly surprised how things work, and, once the frustration wears off, I'm intrigued when things break. Lucky for me, over the last few weeks, I've been surprised, frustrated, and intrigued by what, on the surface, seems like a very trivial problem: MySQL reporting deadlocks in unexpected places and unexplainable slow query log entries when using optimistic concurrency control.

The "test-and-test-and-set" algorithm is a fairly well-understood solution to reducing latency in spin locks. In particular, the algorithm is often employed to reduce the latency exhibited in the similar "test-and-set" algorithm. Understanding how and why a seeming-superfluous read results in lower latency is rather interesting.

Last week, my esteemed colleague and close friend asked a remarkably straight-forward question about downcasting a long to an int in Java. I'll admit the question caught me off guard. While the JLS offered the correct answer, I couldn't help but ponder what's actually happening in the machine.

Java's ConcurrentHashMap is an excellent point of study when learning about Java's Memory Model. It employs numerous techniques to provide lock-free reads while still guaranteeing safe publication of objects. This article represents my attempt to take the magic out of the ConcurrentHashMap implementation.