Hello,
Recently We've ran into a well-known "collection [...] was not processed by flush()" issue with default Hibernate Validator event listener (org.hibernate.cfg.beanvalidation.BeanValidationEventListener) and validator (org.hibernate.validator.engine.ValidatorImpl) implementations.
See following related posts for more details on the issue itself and why it appears:
http://opensource.atlassian.com/project ... wse/HV-246
http://opensource.atlassian.com/project ... e/HHH-2763
(Just for the record, our environment is Hibernate 3.5.3-Final, Spring 3.0.3.RELEASE, Hibernate Validator 4.1.0.Final)

Having debugged the application with Validator sources attached and hibernate.show_sql=true I've managed to track down the place where validator has been referencing lazily-initialized objects.
It turned out that method org.hibernate.validator.engine.resolver.SingleThreadCachedTraversableResolver.buildHashCode(); uses traversed object's hashCode() method, making assumption that hashCode does not depend on lazily-initialized fields.

And of-course our problem was that child object used lazily-initialized parent to build its hash-code. This was done because in most cases we do not use parent object && hash code. And when we use hash code the parent object is always loaded. Well, until now :)

The question is the following: is it the problem in our design which should be changed to eagerly fetch the parent object (if yes then why) or it's a use-case overlook in HV we should try out some workarounds like they suggest in the tickets mentioned above (E.g. extend the BeanValidationEventListener and having access to current session, clear the collection of unprocessed objects which additionally appeared after the validation took place)?

Regards,
Roman

It might be both:
I'm not an expert on this specification so your issue might be rejected, but it makes sense to discuss it so please open a JIRA issue.

But I'm sure that it's bad-practice to define your equals/hashcode including the value of other beans, you should always avoid that and consider what you're defining. It might even make sense to not define the equals/hashcode at all - this really depends on your requirements and not on the used frameworks.

Also consider that your defined equals/hashcode won't work in other cases too if it's not "attached" - kinda weird requirement - or worse yet the performance of these methods might be awful, especially if you insert it into java.util.collections containers.

Hello Sanne,

Thanks for the response. I did create Jira ticket HV-356 as you've requested.
Even though I do agree that it is rather bad practice than a good one, it was convenient for us to use hashCode() and it was appropriate to use lazy properties in the hashCode() because it was always called within spring-managed hibernate session. Until the introduction of validator framework.

I do feel that this issue will rather be considered an end-usage problem. What I would ask though is to provide some (ideas for) workarounds that could be used in the meantime before major code review for changing e.g. from lazy to eager fetching in the future.

Regards,
Roman

just to put this straight: I don't mean to say that it's bad practice to use hashCode(), but that this shouldn't include references to lazy fields - it's not hard to remove them and doubt that any code could meaningful rely on this lazy value to be considered.

Also, I'm not sure about why using it "within spring-managed hibernate session" has you to require an hashCode at all.