I just submitted the draft of my upcoming next book to the publisher to start the review process.
You might wonder what it is about. Well it is about EJB 3.0 and targeted at readers who are already familiar with EJB 2.x and want to know the changes without repeatedly reading things that they already know about.
As there is no final title or cover etc, I can't give them at the moment. Stay tuned, as I will post some more later on.
Dpunkt.verlag is again my publisher, so you might also check out their page about upcoming titles for the anouncement and a link to the final page.
[Update]: Dpunkt has the book description (with the non-final cover) now online
Friday, August 18, 2006
Friday, August 11, 2006
How to outsmart lazy loading
A customer recently had a problem with his O/R mapping framework(*) that all relations between objects/classes were marked to be loaded lazily. Despite this setting, loading a class (either by direct access or via HQL) caused all related classes to be loaded and their related ones as well until the whole graph of attached objects was in memory. The trace of the generated SQL clearly showed this behaviour without any explanation.
Looking at the mapping files, the queries or the java code for the relations brought not explanation. Also the startup of the mapper did not show any errors. The customer even implemented equals() and hashCode().
After having a closer look at the later two methods, the problem came clear: Hibernate did in deed only load the starting class and not the relations (initially). But when putting the entity into the Session, Hibernate has to call equals() or hashcode() for its internal maps. Those two methods now have been implemented my using (amongst other) some relation fields. So in order to compute the hashCode(), the relation had to be loaded (which in turn loaded the next relations, as the hashCode() method on the other classes were implemented in a similar manner).
So actually Hibernate worked as designed :-)
The use of collections within hashCode()/equals() is problematic anyway: a Map uses it to determine the location of the entry. If the hashcode changes this location is no longer correct, which will lead to strange problems.
As a summary: don't only be careful with externally generated primary keys within equals() and hashCode(), but also with using collections.
(*) Actually this was with Hibernate, but the problem can also arise with JDO, JPA etc.
Looking at the mapping files, the queries or the java code for the relations brought not explanation. Also the startup of the mapper did not show any errors. The customer even implemented equals() and hashCode().
After having a closer look at the later two methods, the problem came clear: Hibernate did in deed only load the starting class and not the relations (initially). But when putting the entity into the Session, Hibernate has to call equals() or hashcode() for its internal maps. Those two methods now have been implemented my using (amongst other) some relation fields. So in order to compute the hashCode(), the relation had to be loaded (which in turn loaded the next relations, as the hashCode() method on the other classes were implemented in a similar manner).
So actually Hibernate worked as designed :-)
The use of collections within hashCode()/equals() is problematic anyway: a Map uses it to determine the location of the entry. If the hashcode changes this location is no longer correct, which will lead to strange problems.
As a summary: don't only be careful with externally generated primary keys within equals() and hashCode(), but also with using collections.
(*) Actually this was with Hibernate, but the problem can also arise with JDO, JPA etc.
Subscribe to:
Posts (Atom)