Hi,

I have several sets of objects from the database, each set up to 10,000 in size. E.g. a set of customers, a set of goods, a set of payments, etc. etc.
The user is going to reload these sets with varying query parameters (all customers that haven't paid yet, all customers that live in an area, etc.)

I have a single long-running conversation and persistence context. Each time another query is run, any objects that weren't loaded in a previous query are going to get added to the cache.
The problem with that is that the persistence context's cache will fill up until something runs into an OutOfMemoryException.

What's the best way to deal with that?

Things I have thought of:
1) Somehow tell the session that it should limit the size of its persistence context. There does not seem to be an API for that though.
2) Have the application evict unmodified objects. The code that would have to do this already knows what objects to evict, but it does not know which of them are dirty - is there a way to find that out?

I'll gladly accept any additional ideas :)

I made some investigations about this some time ago. Unless things have changed there is no method that checks if only a specific entity is dirty or not. By digging into the internal API of Hibernate it was at least possible to detect some cases of dirtiness. The old thread about this is here: viewtopic.php?f=1&t=991992

Hm... interceptors are a hook I hadn't thought of.
I wouldn't expect them to work cleanly though. The whole point of Hibernate is to let the program manipulate objects to its heart's desire, and do work only when loading or saving objects. To make the approach work, one would need to do something that triggers event but does not hit the database - that's exactly the kind of things that tend to get optimized out.
I guess the best course of action would be posting a JIRA issue, and do an occasional Session.clear().

Using an interceptor was a wild idea... I don't expect it to work very well and it may have lots of side-effects.

The code in the last post should be possible to work on though. It is (was) based on the code already implemented in the SessionImpl.isDirty() method.

Yep, I had looked at that route, too.
The problem is that a bug in dirty checking can introduce subtle data errors, something I just can't affort for the current project; and that the code is using implementation details, so it could bit rot with every Hibernate update.
So, to use that code, I'd need a massive test suite that handles all relevant cases, and I'd need that suite to pass on every Hibernate upgrade, until Hibernate has a Session.isDirty(Object) of its own.
Unfortunately, I have neither the time nor the knowledge to write such a test suite, so I guess I'll leave it at that.

Anyway, thanks for your help!

BTW the JIRA entry has been made. Maybe we'll see a resolution in due time.