How to refresh a collection?

kbosselman · **Joined:** Sat May 24, 2008 7:34 pm **Posts:** 5

I am working with a detached object, and some other process has updated one of its collections. I'd like to be able to refresh just this collection.

I can force a refresh of the collection by refreshing or reloading the object, however this refreshes everything on the object, so is very inefficient if the object has other large collections that don't need to be refreshed.

Does hibernate provide any mechanism to mark a collection as needing to be reinitialized(ie. stale), so the next time it is accessed it will refresh the collection from the db?

Thanks

sanne.grinovero · **Posted:** Sun May 25, 2008 4:43 am

Hi, you should configure a second-level cache, so it's not your business logic to have to bother with this details.
Just get a fresh copy of your entity, the caching system will know what is changed and what is needing an update; it actually could get the updated values from cache (having being put by your other process) instead of DB so you get even higher performance than by reloading the collection only.

If the other process changing your data is external to hibernate, mark your collection as not-cacheable, so you get a cached copy for other properties of your entity but a fresh read of data for your collection.

kbosselman · **Joined:** Sat May 24, 2008 7:34 pm **Posts:** 5

Thanks for the reply.

I played around with the second level cache and understand what you're suggesting. However, for our problem space using the second level cache didn't seem like much of a win. User data is very segregated so the likelyhood of cache hits is low and there is also a very low level of concurrency issues. So avoiding the overhead of maintaining a distributed cache (across 40+ servers) and just manually dealing with the few edge cases where concurrency was an issue seemed the best way to go.

I'm suprised there doesn't appear to be an API to reset the wasInitialized flag on a collection to force a reload.

sanne.grinovero · **Posted:** Sun May 25, 2008 1:45 pm

you don't need to use a distributed cache for this scenario, just eh-cache is simple to configure and very efficient.

If you needed your cache to be safe across the cluster you really wouldn't keep some data not refreshing, or you would introduce some serious problem; I'm just telling you how to cache the data exactly as you wanted it.

kbosselman · **Joined:** Sat May 24, 2008 7:34 pm **Posts:** 5

While I appreciate your thoughts, I still not convinced that in our particular use case going to a second level cache would be the best solution.

My point of the cache not being a win for us, is that if we aren't using the cache to handle concurrency across servers, it is providing little benefit. And even if we do go to a distributed cache, the cost incurred to handle what is an edgy case would seem to be very high.

In the general use case we already have the object tree in memory as we want it, so there is no need to worry about reading and writing the objects to and from a second level cache. There is very little overlap in data between threads so keeping a cached copy of something you are unlikely to need to access again provides little benefit. The few cases where there are concurrency issues could be easily handled if we could refresh collections individually.

If we go to a local cache we are still going to have to handle concurrency issues manually, plus we would incur the additional cost of maintaining the local cache, while gaining little true benefit. Not handling the concurrency manually and just turning the caching of the relationship off would also be inefficient as that would force a re-read of the relationship every time we accessed it, when it is an edge case to need the data refreshed.

So while implementing a second level cache may indeed solve my issue it would seem to be a heavyweight solution to what I see as a lightweight problem.

sanne.grinovero · **Posted:** Sun May 25, 2008 4:40 pm

Hi kbosselman,
don't worry I appreciate a good discussion ;-)

Quote:

turning the caching of the relationship off would also be inefficient as that would force a re-read of the relationship every time we accessed it

this is not true, there's first level cache too: until you detach your object graph from the session you are not going to repeat unnecessary data reads.

Quote:

there is no need to worry about reading and writing the objects to and from a second level cache

You don't have to, wen you enable it it's Hibernato who will put and get objects from the cache, no code changes.

Quote:

If we go to a local cache we are still going to have to handle concurrency issues manually

You have to handle them anyway, at least handling optimistic locking; please remember your first level cache can't be turned off; also keeping objects a long time enlarges your probability of stale data, so reloading the objects often is a good thing: when it's unneeded the cache will tell you transparently, automatically, and you can change this policies from outside the code, even replacing your cache manager.

Quote:

So while implementing a second level cache may indeed solve my issue it would seem to be a heavyweight solution to what I see as a lightweight problem.

so I think we are actually speaking about the same solution in different words; what you are saying is that you want to keep the main object (I call that caching) and reload the collection, using some lightweight solution; eh-cache really is quite lightweight.

kind regards,

kbosselman · **Joined:** Sat May 24, 2008 7:34 pm **Posts:** 5

s.grinovero wrote:

Hi kbosselman,
don't worry I appreciate a good discussion ;-)

Quote:

turning the caching of the relationship off would also be inefficient as that would force a re-read of the relationship every time we accessed it

this is not true, there's first level cache too: until you detach your object graph from the session you are not going to repeat unnecessary data reads.

-- We're using a short transaction model so our objects are mostly detached and then reattached when necessary, so the first level cache only comes into play ligthly. The general use case would have the relationship being re-read repeatedly.

Quote:

there is no need to worry about reading and writing the objects to and from a second level cache

You don't have to, wen you enable it it's Hibernato who will put and get objects from the cache, no code changes.

-- While this is true, there is no coding involved, putting and getting things from the second level cache is not free. In my limited testing using ehcache, at times it took longer to retreive an object from the cache than it did from the db.

Quote:

If we go to a local cache we are still going to have to handle concurrency issues manually

You have to handle them anyway, at least handling optimistic locking; please remember your first level cache can't be turned off; also keeping objects a long time enlarges your probability of stale data, so reloading the objects often is a good thing: when it's unneeded the cache will tell you transparently, automatically, and you can change this policies from outside the code, even replacing your cache manager.

-- Since our problem space has very limited concurrency issues dealing with stale data is of less importance than limiting extra data acceses. In the general use case we can (safely) optimistically assume that the data we have in memory is not stale, so best performance is achieved if we can avoid unecessary re-reading of data from either the second-level cache or the db.

Quote:

So while implementing a second level cache may indeed solve my issue it would seem to be a heavyweight solution to what I see as a lightweight problem.

so I think we are actually speaking about the same solution in different words; what you are saying is that you want to keep the main object (I call that caching) and reload the collection, using some lightweight solution; eh-cache really is quite lightweight.

-- I can definitely see use cases where relying on the second level cache is the thing to do, I just don't see where it fits our specific model very well. If we were more concerned about concurrency/stale data than limiting data accesses and if we had more data being shared between threads using the second level cache would then be worth the cost. (Which may be small in terms of coding, but no matter how light weight eh-cache is it is certainly not free in terms of performance)

kind regards,