I have a parent entity with two lazy lists of child entities. To simplify searches for distinct entities, the parent entity has a 'hash' field which is a calculated value based on data in the parent and all of the children - when the 'getHash' for that field is called, the hash is recalculated (i.e. if the user changes a child's value, the parent hash value will change)

The mapping looks like this:



If I load the parent and then (without accessing either of the children) evict it, the evict code is retrieving the values for all of the fields - and when it hits the getHash() method, getHash() fails with



The code looks like this:



One odd thing in here is that the failure is when the code tries to access the *second* collection - getHash() has already retrieved one of the lazy collections successfully before the above exception is thrown:




If I initialize the children before calling session.evict(parent), then it all works (for example, by calling my parent.toString() which visits all of the children). If I call session.clear() instead of evict, it works - but that is rather heavy-handed, as there are times when I want to evict a subset of my entities rather than all of them.

Another down side (besides the exception being thrown...) is that it looks like evict() is going to visit all of the entities I wish to evict - which (due to the hash calculation for the child collections) is expensive - for example, if I just want to get the values a parent-defined field without loading the children, that isn't going to work efficiently any more as evict() is going to (unnecessarily) load every child.

So... Is there something I'm missing in my mapping or elsewhere that would affect that evict() behavior (ideally the visiting of every field in the entities but at least stopping the exception from being thrown)? Or is there some way I can tell (in my getHash() method) that the caller doesn't *really* need the most up-to-date hash value (i.e. the caller is doing an evict rather than a save/update/...) and I can safely skip the calculation?

The solution has to retain the connection between parent and child - the real code just loads and saves the parent entity - it depends on the mapping relationships to make sure any contained children are persisted when the parent is persisted. I would hate to have to change all of that code so it persisted each child individually rather than just the parent...

Hibernate: hibernate-distribution-3.3.2.GA
java: 1.6.0_15

Thanks!

After some debugging, the entity is being loaded twice and the old version has its session set to null - but the top level getHash() code is holding onto a reference of the old (uninitialized, sessionless) version, not the new (initialized) version.

Unsetting the session happens in StatefulPersistenceContext.java:



And, looking at the object graph, the 'watch out for a case...' statement is true. The getHash() method in Group has a copy of the child lists with their parent Group field set to 'Group_$$_javassist_2 (id=XX)'. When the first list in getHash() is accessed, Hibernate initializes both lists - which means the second list in the Group's 'this' loses its session (but is still has its group set to 'Group_$$_javassist_2 (id=XX)') so Hibernate a) thinks it is still uninitialized and b) can no longer initialize it.

So... does anyone have any tips on how to unravel the 'which is a user error' part of the 'watch out for ...' comment? I don't have a session object in my getHash(), so cannot initialize the lists manually (I think - or is there some way to figure out the session context a method is being called from within)? And, I'd rather (for an evict) not incur the cost of loading my child collections in the first place - but again, not sure how I would detect that condition vs a valid call (such as during a save or update call).

Thanks.

I would recommend that you simplify your code. The getHash()/setHash() methods are better off being as simple as possible. Eg.



Then, add a method, for example, calculateHash() that updates the hash value and that you can control yourself when it is called. I have been down a similar path as you and realized that it is never possible to know when or why Hibernate will call a setter/getter method in your mapped classes. It can happen often, and in your case I guess it could be quite expensive if the collections are large.

Yes, I originally started down that path. The actual code is quite a bit more complex, and there are places where methods manipulate the child collections without having an instance of the parent class, so they cannot (currently) call caclulateHash() on the parent. Having the getHash() calculate the value solved that, as it gets called on the parent by Hibernate if the child entity is persisted.

The code has a few spots where the entities are created or updated, and lots of spots where they are read. The cost of doing the calculation is the same (ignoring the 'calculate on evict' issue) whether the calculation is initiated manually via a caclulateHash() method or automatically by Hibernate. But, since Hibernate seem to evaluate all fields on evict(), your 'it could be quite expensive' comment is applicable.

Ideally I would be able to evict without incurring that cost, but if that cannot be done I guess a manual calculation is the solution.

Thanks for your time!