Discussions

News: Demystifying Hibernate Cache - The Second-Level Cache

  1. Hibernate provides powerful caching mechanisms which can help increasing performance and scalability of your application. However besides the benefits there are also pitfalls, which can only be avoided if one understands the inner workings of Hibernate and the dynamics of it's caching behavior. Read more at http://blog.dynatrace.com/2009/03/24/understanding-caching-in-hibernate-part-three-the-second-level-cache/ The first two posts already created a lot of discussion on whether to use and how to use O/R mappers. In this post the inner workings of the second-level cache is unveiled. Please also post your experiences or pitfalls you came across.
  2. This has got to be the most painfully verbose way of performing resource transaction analysis. The essence of database transaction (data access interaction) is completely lost and we have to walk through up/down/across each call path to actually determine what the transaction looks like. A Pure waste of time. This clearly does not scale at runtime (huge collection cost) or at analysis time (huge headache). William
  3. William, this was about explaining the inner workings of the cache not about doing a full runtime analysis. However your nice and productive comments are always welcome - Alois
  4. Alois, This is nothing to do with showing the inner workings. You would be quicker reading the source code for that matter. Show us something really interesting & new and we can all ignore the obvious product pitch. Can you also be productive in your comments and actually respond to my claims? This is a huge overhead both at runtime during data collection and offline during analysis. William
  5. Hibernate's second level cache is completely worthless. A database is much more optimized for caching. Especially in combination with SSD disks for the DB, the cache is more than completely worthless (utterly worthless?). Hibernate caching is just an unnecessary extra layer that introduces extra complexity in the system. Such extra layers should be removed as much as possible. In a way, the cache is even semantical incorrect. Namely, when I change data in the DB and then retrieve this data via the entity manager, it returns the old data. I went out of my way to make sure all Hibernate caching that I added before was completely removed from my code.
  6. Hibernate's second level cache is completely worthless.
    For frequent read-only operations, it's a God send. Esp when working w/ data which requires many different views (not db views, eye views). Such data and such systems out there exist.
  7. A database is much more optimized for caching.
    I forgot to ask in my reply, how does one cache the network? Say I request a large large number of rows of data, and the database can start its response immediately. What happens if I have fifty machines hooked up to a database in that regard. What of my network?
  8. Hibernate's second level cache is completely worthless.
    hilarious sentence. you really don't know what you are talking about. The caching helps in an incredible manner, by orders of magnitude, in high volume, highly reactive systems, for example for web systems producing computational expensive reports on the fly.
    A database is much more optimized for caching.
    This sentence proof how bad is your understanding and usage of the second level caching (and application caching in general). Your sentence is meaningful probably just in trivial crud-like application, where the application data domain is one-to-one with the dbms domain. However, when your application is a real application, not a simple interface to the dbms, just to read and save data, there is no relation between the application data caching and the DBMS records caching. The DBMS could cache a bid for example; the application could cache a full report with complicated computation behind involving thousands of bids.
    In a way, the cache is even semantical incorrect. Namely, when I change data in the DB and then retrieve this data via the entity manager, it returns the old data.
    another meaningless sentence. The contract of every caching system declares the its usage forbids any underlying manual data manipulation. If you have multiple systems accessing yor dbms directly, not through hibernate, you cannot use hibernate second level caching, and no other application caching of course, that's it. You could even use your personally implemented application caching (with any caching framework not tied to the dbms like oscache for example or with your framework) but if someone is manually changing data on the dbms, or another system directly accesses the dbms without invalidating your cache, you simply cannot use a caching system, because it invalidates your application data !