views:

271

answers:

2

"Dirty reads", meaning reading an object's value even though it is write-locked by another thread, are described on Terracotta's website, yet I've heard that they shouldn't be used, even if you don't care about the possibility that you might get old data when you dirty-read the locked object.

Does anyone have any experience of using dirty reads in Terracotta, and are they safe to use if you don't care about the possibility of reading an old value?

+3  A: 

A dirty read is a dirty read. Terracotta, being distributed/clustered, only adds the possibility to read even older values of the shared mutable state that you are accessing without proper synchronization.

You should note that, under the memory model in Java 5, you are not guaranteed to ever read an updated value if you don't use proper synchronization. Terracotta may decide to take advantage of this possibility. In fact, any JVM may, at their leisure, take advantage of it. Even if it might work on your machine, it may break on other machines. It may break on minor updates of the JVM, and it may break for the same version of the same JVM on a different CPU.

With that in mind, you can say that dirty reads isn't safe in any JVM... Unless you don't mind the possibility that you won't ever be able to read the updates that other threads make - an unlikely situation but it could happen.

Also, when you actually follow your link to Terracottas wiki, it says that the article has been removed and that the pattern is discouraged.

Christian Vest Hansen
Yes, it was removed as a result of my conversation with a Terracotta sales engineer.
sanity
+1  A: 

I'm a Terracotta developer. The gist of the answer is just as Christian Vest Hansen already noted - just as the JVM makes no guarantees about the visibility of updates of a shared object that is accessed w/o proper synchronization, Terracotta likewise can make no guarantees about dirty reads of a clustered object.

The link has indeed purposely been removed and replaced with a warning to not use this pattern.

Scott Bale