JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 277 contents

Eventual consistency is where an update is successfully made to a data store, but you are not guaranteed to see the updated values immediately. Instead, reads can see the old values, and "eventually" will see the updated values. Strict consistency is the (possibly more familiar) situation where any read after a successful update will definitely see the updated values. Relational databases typically provide strict consistency. NoSQL databases typically provide eventual consistency. Each have capabilities to provide the other type of consistency, but not as efficiently.

What's interesting is the reason why eventual consistency has become the more popular mechanism: because of the lower latency of data access. Strict consistency means when you update, you have to wait for any ongoing reads to finish - even across an entire distributed datastore. Then to complete the update you need stop any reads happening until the values are changed - again potentially across an entire distributed datastore. You can see that for a distibuted datastore, that is a huge delay. Even for a single-node data store, there is still a coordinated lock overhead. Eventual consistency let's the reads and writes happen concurrently without interruption, which means much faster access when there is also a significant write load. That latency advantage together with the fact that most accessed data can be slightly out of date (eg with social media feeds, if you don't see someone else's update until a few seconds later, it's not a problem) means eventual consistency is a much better fit for most data. You'll notice that payment transactions on websites always take more time than most other operations, and that's because they need to use strict consistency with a distributed transaction, whereas most other data can use eventual consistency.

Although not directly relevant, these thoughts about eventual consistency came to mind when a colleague pointed me at Lowan Holde's delightful quote I love how bank transfers are the canonical DB transaction example when banks take days to execute them and allow dirty reads the entire time. Now on to all the usual newsletter list of links, tips, tools, news and articles, and as usual I've extracted all the tips into this month's tips page

A note from this newsletter's sponsor

News

Java performance tuning related news

• The frequency of allocations matter more than the size of allocations, profilers such as JFR are biased to large allocations and allocation sizes
• Walking through finding the cause of a Java native memory leak in Pinterest infrastructure (it was not explicitly closing a native resource - it could then get closed by GC finalization, but if GCs are not occurring frequently enough ... effectively a native leak)
• (2022) "Java Memory Management" By Maaike van Putten, Sean Kennedy, Publisher: Packt Publishing

Tools

Java performance tuning related tools

• Ways to inspect the contents of Java's Metaspace Region (with examples): -verbose:class, -Xlog:class+load, jcmd GC.class_histogram, Guava ClassPath.from(), analyzing a heap dump
• Types of thread synchronization errors: Race conditions (the behavior of a program changes unpredictably depending on the relative timing of events); Deadlocks (two or more threads are blocked forever, each waiting for another blocked thread to release a lock); Starvation (a thread is unable to gain regular access to shared resources and is unable to make progress); Data inconsistency (multiple threads access shared data without proper synchronization, leading to unexpected and incorrect results)
• IBM Thread and Monitor Dump Analyzer for Java (TMDA) allows identification of hangs, deadlocks, resource contention, and bottlenecks in Java thread dumps

Articles

• Java Memory Leaks: Silent Killers in Your Application (Skilled Coder/Javarevisited)
• Bare metal Java (Jaroslaw Palka/GeeCON)
• Optimizing Java for Low-Latency Applications (Alexander Obregon/Stackademic)

Jack Shirazi

Back to newsletter 277 contents