#thread safe

Learn Java Programming - Creating a Thread Part Three Tutorial

http://iilii.egloos.com/m/5350490

Talking about threads, first phrase that used to strike me was "Thread Safe Code". But is code the real problem? Certainly not. The problem is the data that multiple threads are accessing simultaneously. Reassigning the same references or calling non thread safe state changing methods in parallel is the real problem. The term Scoped container is generally used for HTTP Session, Request or ServletContext; which can be used for making the web application stateful. But none of these are designed to be thread safe. But also apart from these containers, i am considering containers as varied as the object or query caches to even simple globally accessible map. Following are the few strategies I have gathered from seeing code, reading articles and with few mistakes. They are in the order I would try to implement.

Use only immutable objects in cache - This way you will never loose atomicity. The perennial problem of corrupt data can be completely avoided.

Don't mutate after set - Even if you are using mutable objects, make it a coding practice that once object is passed to cache none of the mutators are called. This can be grave problem with clustered applications where caches are synchronized across multiple instances. The process of synchronization is started with the object reference update or addition, and very much possible that its completed before the object mutators are called. This way two supposedly synchronized caches differ in their object states.

Use java.util.concurrent.atomic package - This package provides wrappers around regular java datatypes and generic classes like AtomicReference which can be used to access regular objects as if they were volatile references. You can get more details here..