Daniel Rosenbaum
Mon, 07 Mar 2005 16:01:17 -0800
> Personally, I wouldn't cache inside Hibernate. I'd > roll my own outside so I have more control. Caching > is too hard to leave it up to a tool with a generic > solution. We can move on anyway.
Hibernate makes it easy to cache and has a feature I find particularly attractive, which is the query cache. Hibernate saves the last update timestamp of any time a row in any table was updated, or an insert or delete performed. When a query is performed and the result set is already cached, the last update timestamps are checked behind the scenes for all tables involved in the query. If any of the timestamps are later than the time the query is performed, the cached result set is disregarded and a new trip to the database is performed. This is a good thing, since now I do not keep track of all queries that may use a particular object, and can rely on Hibernate to do this checking for me. To implement this myself would be much more difficult. > > If you are not trying to get from other laterals, then > yes, remove on put is useful for data that is most > likely associated with a single user, but could affect > others, in a sticky load balanced situation. > > If you have get enabled, then this isn't a concern. B > would try to get from A and the endless invalidation > would never have started. The remote cache is best > for this. > > It is better to just put on put for other kinds of > data. It is not that expensive. > What does it mean to have get enabled? Does this mean that on a get from the cache the first thing it will do is send a message to the other servers asking if anyone has that object and if so send it across the wire? Assuming it is this, how much time would the process wait for a response before giving up and going to the db? If it is a short time, then could the lateral be configured that if a cache entry is put on A an invalidate message is sent to B, and if B then asks for that entry A would send it, rather than going to the database? If I understand you correctly this is exactly what should happen. As a side question, wouldn't gets be slower when getting something not already in the cache, because of the time it must wait when asking the other caches if anyone else has a copy? What affect would this have on performance of an app, especially if many gets are performed on loading a page? > > That depends. Some data is ok stale. Bank account > data isn't. The description of a book or some other > item at an online store, like the one I work for, is > ok. > In my case, some of my data is ok stale, but others it is critical that it not be stale. Otherwise it would make the user go "huh? but I just changed that! What a piece of junk." This is data that is rarely changed, and is expensive to load fresh, but on the occasion that it is changed it must be correct right away. I am particularly interested if anyone has any comments of using JCS with Hibernate. Have they had any issues with distribution? Also, I think a problem was reported once with serialization of Hibernate objects, does anyone know if this has been corrected? (If my memory serves me correctly it was Travis Savo who reported this problem. Travis, if you are reading this, could you please comment? Thanks.) Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]