Discussions

News: ehcache-1.2 released - distributed caching, listeners and more

  1. After 10 months of development, ehcache-1.2 has been released. The 1.2 release of ehcache has many new features including:
    • Flexible, extensible, high performance distributed caching. The default implementation supports cache discovery via multicast or manual configuration. Updates are delivered either asynchronously or synchronously via custom RMI connections. Additional discovery or delivery schemes can be plugged in by third parties.
    • New FIFO and LFU caching policies in addition to the standard LRU.
    • Introduced CacheManagerEventListener and CacheEventListener interfaces and default implementations.
    • Multiple CacheManagers per virtual machine.
    • Programmatic flushing of application state to persistent caches
    • Significant (up to 7 fold) DiskStore performance increases.
    • API for Objects in addition to Serializable. Non-serializable Objects can use all parts of ehcache except for DiskStore and replication. Two new methods on Element: getObjectValue and getKeyValue are the only API differences between the Serializable and Object APIs.
    • Backward Compatibility with ehcache-1.1. All users of ehcache-1.1 should be able to upgrade to ehcache-1.2.
    • Tested with Hibernate2.1.8 and Hibernate3.1.3, which can utilise all of the new features except for Object API and multiple session factories each using a different ehcache CacheManager. A new <tt>net.sf.ehcache.hibernate.EhCacheProvider</tt> makes those additional features available to Hibernate-3.1.3. A version of the new provider should make it into the Hibernate3.2 release.
    • Tested with ehcache-constructs.
    • Apache 2.0 license.
    An interesting question for a serverside discussion is how important do people think these features are, and what are the most requested features for a caching framework?
  2. Concurrency control[ Go to top ]

    An interesting question for a serverside discussion is how important do people think these features are, and what are the most requested features for a caching framework?

    Can you explain how you implemented support for XA transactions and concurrency control? Specifically, both for the case of two transactions on the same node and for 2 transactions on different nodes.

    Thanks
    Guglielmo

    Enjoy the Fastest Known Totally Ordered Reliable Multicast Protocol

    .. or the World's First Pure Java Terminal Driver
  3. Concurrency control[ Go to top ]

    There is no distributed transaction support in this version. It is something being considered for the next version. I am interested in whether people would use it. This previous thread, http://www.theserverside.com/news/thread.tss?thread_id=28445#136771, seems to give the answer that it is maybe used 1% of the time.

    Part of the issue we face is that there are other systems outside of our Java app which are making updates to the database.

    If you want to be certain that you have the latest read committed data, skip the cache and go to the canonical source. Often though data can be a bit stale. Some features in the ehcache implementation are:

    - replicate updates, either by copy or invalidate
    - the choice to do this synchronously

    So lets say you update the cache while holding a lock to the database row within your transaction.

    The cache sends a synchronous invalidation message to all cache peers. Those cache peers lose their now stale copy. If those systems need the data and they are also set to read committed, they will queue up until the commit is called.

    If instead we send a synchronous update via copy, the peers get the new data and do not need to go back to the database.

    Finally, if it is ok for their to be a 1 second delay, they could use the asynchronous replication option. Here the other peers have stale data following the database commit until the update propagates to them.
  4. Concurrency control[ Go to top ]

    There is no distributed transaction support in this version. It is something being considered for the next version. I am interested in whether people would use it. This previous thread, http://www.theserverside.com/news/thread.tss?thread_id=28445#136771, seems to give the answer that it is maybe used 1% of the time.

    Anybody who uses transactional jms messaging will need you to support XA. That's just one example.
    Part of the issue we face is that there are other systems outside of our Java app which are making updates to the database.

    But there is a huge space of applications where this does not happen.

    And besides, there are ways for the database to notify your cache as well. Although most people have never tried it.
     If you want to be certain that you have the latest read committed data, skip the cache and go to the canonical source. Often though data can be a bit stale. Some features in the ehcache implementation are:- replicate updates, either by copy or invalidate- the choice to do this synchronously So lets say you update the cache while holding a lock to the database row within your transaction. The cache sends a synchronous invalidation message to all cache peers. Those cache peers lose their now stale copy. If those systems need the data and they are also set to read committed, they will queue up until the commit is called.If instead we send a synchronous update via copy, the peers get the new data and do not need to go back to the database.

    Ok.

    You make it sound like holding a lock is optional. Does that mean that if one decides not to hold a lock and there are concurrent writes then you invalidate the transaction at the end and roll it back? Or you just forget about it?

    Guglielmo
  5. Thank god for the new support for multiple CacheManagers. ehcache is one of the last major libraries which uses statics and classloader "magic" to load its config file (Velocity also comes to mind). This made it unusable in an application with multiple databases. Programmatic configuration in code or Spring is a welcome addition.
  6. We are using Hibernate-3.1.2 with JBoss-3.2.3. For second level caching of Hibernate objects we opted JBossCache, because it had clustering support, which the earlier versions of EHCache did not have. Now, when its mentioned that EHCache-1.2 has distributed caching, does this mean that EHCache-1.2 can be used as a second-level cache for Hibernate-3.1.2 in a clustered environment with <cache usage="transactional"/> in the hbm files?
  7. Hello, Could you find answer for question : Can we use EHCACHE(latest version) with configuration ? Please reply. Thanks, Abhay R. Dani