Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

News December 2023

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC 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

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

Get rid of your performance problems and memory leaks!


Java performance tuning related news


Java performance tuning related tools


Jack Shirazi

Back to newsletter 277 contents

Last Updated: 2024-06-30
Copyright © 2000-2024 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us