Hello, I have a web application that runs for a period of 2 months. In the first week users register themselves. After that, there are very minor changes in the database. At week 6, about 5 entities are heavily changed.

I have about 70 entities in my system. Should I cache them all (or almost all)? My whole database uses 40MB of disk space at the end of 2 months.

I know that about caching:
- Use caching only if you need to improve performance
- Cache only enough so that performance is at an acceptable level

But I would like to hear your opinions on the pros/cons of this approach, as well as some other parameters I can use to choose my cached entities.

Will too much cache slow down performance? Would it be better to use an in-memory database?

Bear in mind this is application is reseted each 2 months.

thanks

Using a cache is usually depends on your use cases. Caching everything is not necessarily a good idea. Caching static data like list of countries is usually an improvement but if you don't have much database hit then you will not benefit much from this either. Mutable entities are usually the trouble here since hibernate per se, for obvious reasons, does not check database to see if there is a newer version of data it is caching. Therefore, then the programmer should always think up front for how long an object should be cached. For example, if you are caching business rules which can be edited then you should ask your business analysts how fast edited rules should come into the live system. If immediately then you can not cache those objects or you can cache them for short periods like 1 minute. This is kind of short term caching is only useful if again you have a high database hit rate. Remember these days databases have a good cache themselves so on a low hit rate the database cache is fairly enough.

I hope this helps.

Farzad-

Yeah, about the caching strategy, I'm using read-write. So the time the object should be cached is not a problem. Since there is no direct interaction with my database from external sources, I belive its safe to use an eternal cache, whenever memory is not a problem.

"High hit database" is also another good filtering criteria to choose my cached objects. Thanks.

If you use autoflush mode (which is default), the cached objects are checked for changes on every query. This can degrade performance severely. If you use spring you can optimize this behaviour by defining read-only-transactions, which internally just switches the flush mode. But write-transactions still can be very slow. I experienced business cases which needed about 5 seconds to terminate in my environment without second level cache and about 40 seconds with second level cache enabled and about 2000 objects cached. It depends on the number of queries in the business case of course.
An in memory database might be a better choice.

Best regards,
Maarten Donders

Thanks for the reply. I am using spring's support to set "read-only" transactions as well.

Does anybody else has an opinion?