Let’s start with the well known LazyInitializationException. When you search for this one in the Internet you end up with scenarios like this one:

You load A, close the session you  used and try to access a property of A which gets loaded lazily resulting in a LazyInitializationException. That one is well described, including strategies to avoid it, which basically consist of not closing the session to early.

But there are more hideous scenarios. Assume the classes Mom, Dad and Kid are mapped as one would expect, with references from Mom and Dad to Kid. Now consider the following piece of code:

Depending on your exact Mapping you might get a LazyInitializationException in the last line, although the session is still open. The problem here is that when dad got evicted the kid got evicted as well. And since Mom has a reference to the exact same object, that object isn’t attached to any session anymore. In order to see this effect you’ll have to use mappings like this:

The NonUniqueObjectException gets caused by what could be considered the reverse process. Examine the following piece of code:

The first method call loads a Dad object including Kid from a different session. Then from the ‘main’ session Mom gets loaded including kid. When we attach the Dad object to the session it tries to attach its version of the Kid as well, which collides with the Kid already present in the session.

So how can we avoid these kind of problem? I see several options:

• Don’t use Cascade. Of course this means much more effort on your side in many cases, since you have to carefully track what you need to attach or evict from a session.
• Don’t use evict and don’t reattach existing instances to sessions. I guess this should work in many cases. But I have seen cases where this approach would have caused a large overhead, because reloading complex object graphs.
• Carefully design your cascading boundaries. A look at the Aggregate Root from DDD might help here. An Aggregate Root is a single class which works as a gate keeper (did anybody say facade) to a cluster of classes related to the Aggregate Root. When all the Hibernate related actions go against that Aggregate Root, and cascade from there to the content and only the content of the Aggregate Root you should be safe. All entities outside an Aggregate Root have to use the Aggregate Root or Repositories to gain access. This needs some bookkeeping. But when you do it properly it might actually improve the over all design of your code. Please note that all this is a thought experiment on my side, and I can’t promise that it actually works as intended, but I think it should.

If you want the complete source code for the example, you can download this source.zip file.

Entgegen der allgegenwärtigen Presens von Objekt Orientiertem Design in der Literatur und im Internet kommen in meiner Erfahrung diese Techniken oft nur im Infrastruktur Code zur Anwendung (GUI Frameworks, Web Frameworks, Datenbankzugriff …). Wenn es aber um das eigentliche Problem geht, ist die Basis auf einmal das Datenmodell. Ich weiß um den Wert einer guten Datenbank. Aber die Möglichkeiten Geschäftslogik in der Datenbank sichtbar zu machen sind extrem beschränkt. Es gibt nicht viel mehr als Foreign Keys, um Beziehungen zwischen Daten zu repräsentieren. Es ist also völlig ungeeignet das Domänen Modell, dass jeder Anwendung zu Grunde liegt wiederzuspiegeln. Wenn es aber nicht im Sourcecode ist, wo ist es dann? Gemäß Agilen Methoden: Nirgends, jedenfalls nicht in schriftlicher Form. Und gemäß Wasserfall oder V-Modell oder dergleichen? In einem veralteten Dokument!

Martin Fowler schlägt als anwendbares Enterprise Pattern das Domainmodel vor, das nach allen Regeln der objektorientierten Kunst erstellt wird. Evans liefert in seinem Buch nun das Handwerkszeug, um mit diesem Domänen Model möglichst produktiv zu arbeiten. Er beschreibt wie Refactoring, Patterns, Modularisierung und vieles mehr in diesem Kontext eingesetzt werden können um das Domänen Model im Source Code ausdrucksstark zu halten und wie es als Grundlage für eine gemeinsame Sprache (Ubiquitous Language) zur Basis sämtlicher Arbeit im Projekt wird. Dies alleine wäre schon Grund genug das Buch zur Pflicht für jeden Softwaredesigner und Architekten zu machen. Hinzu kommt, dass es sich sehr angenehm liest, unter anderem da er realitätsnahe Beispiele verwendet und Beispiele aus der eigenen Erfahrung bringt die zeigen was nicht funktioniert.

In manchen Reviews werden ihm Wiederholungen vorgeworfen. Einiges was so mancher für Wiederholungen hält, sind keine, sondern nur ähnliche oder verwandte Konzepte. Vieles schreibt aber tatsächlich mehrfach, allerdings in einem Umfang, den ich als sehr angenehm empfand.

Äußerst empfehlenswert.