Discussions

Performance and scalability: Cache: Concurrency Strategy and Performance

  1. Cache: Concurrency Strategy and Performance (4 messages)

    Recently I evaluated following cache solutions: OSCache EHCache WhirlyCache Cache4J WhirlyCache is the most promising: they minimized amount of synchronized statements. Cache4J is attractive too: small amount of code! OSCache still has a weaknesses such as server blocked frequently with many threads locking the same object EHCache lacks in performance (probably too many synchronized objects...) All caches have boring LRU, FIFO, etc... ORA-01555: snapshot too old Why can't we use this instead of synchronization blocks? We can manage Concurrency Strategy for WebLogic’s EJB (cached objects!), so why can’t we do it in HashMap implementation!!? Need to start own... MyHashMap Here is a sample to start with, first of all I need own implementation of a Map. I'll store there wrappers of real objects, and each entity should have implemented hashCode(), equals(), and clone() methods. No any synchronized blocks anymore! Of course, I'll need new parameters such as CONCURRENCY_STRATEGY: optimistic, pessimistic, and ERROR_HANDLING: auto, ignore, notify. public CachedObject { public volatile boolean stale = false; public final Object object; } 1. We can safely retrieve an object from a cach for read-only operation 2. We can do following to modify an object: - mark a field stale as true (either before or after modifying an object; depends on concurrency strategy) - return a copy of an object using clone() method - put this modified object into cache (and check equals()) ... Thanks, Fuad
  2. We can do following to modify an object:
    - mark a field stale as true (either before or after modifying an object; depends on concurrency strategy)
    - return a copy of an object using clone() method
    - put this modified object into cache (and check equals())
    ...


    Thanks,
    Fuad
    There is still a hole in this implementation. If two threads are competing for the same object you could have a situation where: 1. Thread1 checks to see if the object is stale--it isn't. 2. Thread2 marks the object as stale and gets a clone. 3. Thread1 marks the object as stale (again) and gets a clone. Now both threads think they have the latest version of the object, and there will be no way to prevent the last one in from overwriting the first's changes. There are various OS scheduler race conditions that will prevent equals() usage from assuring that one thread doesn't overwrite another's changes. When it comes down to brass-tax, the only way to optimize for concurrent processing contention is through the usage of proper lock granularity (depending on your access patterns) and other strategies to isolate groups of threads so they work on data partitions that don't have the possiblity of contention outside of their group. Lock aquisition/release is a necessary evil . . . Cheers, Gideon GemFire--The Enterprise Data Fabric http://www.gemstone.com
  3. ORA-01555: snapshot too old Why can't we use this instead of synchronization blocks?
    It's called MVCC, and you can find lots of information on it via Google. However, you aren't looking for "just a cache" at that point, since you listed out a whole bunch of "just a cache" products, but you are actually looking for something that is transactional and coherent. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  4. have you tried jboss cache ?? http://www.jboss.org/products/jbosscache JBoss Cache’s ability to distribute and maintain data caches allows you to build large-scale systems that outperform traditional client-server database systems. JBoss Cache is designed for the middle-tier and delivers cached data to users at in-memory speed. Specifically, JBossCache can be used in three scenarios: » Local cache, without any replication » Replicated cache, using non-blocking, asynchronous replication » Replicated cache, using blocking, synchronous replication
  5. JSE[ Go to top ]

    Java 5 provides new classes such as ConcurrentHashMap, WeakHashMap, etc... Unfortunately many developers still rely on full-fledged products in many trivial cases such as standalone JEE application, or even cluster with session affinity (many use it!) Why can't we use a database instead of cache? In fact, we use it: EHCache promised JMS-based transactional cache replication, and JMS _must_ have a persistence layer such as a database!!!