Letzte Woche habe ich meinen neuen Vortrag „Java & SQL – gemeinsam Stärker“ als kostenloses Webinar auf Englisch präsentiert.
Die (aktualisierten) Folien gibt es als PDF-Download (10MB), das Video ist auch auf Vimeo verfügbar.
Sponsoren: ProHuddle and Gitora
Dieses Webinar wurde von ProHuddle, Engaging Webinars with IT Professionals, organisiert und von Gitora, Version Control for Oracle, unterstützt.
Das Wesentliche:
Software-Schichten machen viele Dinge einfacher, stellen aber nicht 100% der Funktionalität der darunter liegenden Schichten zur Verfügung.
Was ist der richtige Abstraktionslevel für jedes Problem?
Der ORM-Zyklus: Daten in die Applikation laden, dort ändern und die Änderungen zurückspeichern.
Muster #1: Wenn der Zyklus durchbrochen ist, ist die ORM-Schicht vielleicht nicht der richtige Abstraktionslevel. Beispiel: Listen im entferntesten Sinne.
SQL hat sich über die relationale Idee hinaus entwickelt. Rekursionen sind ein Beispiel für eine nicht-relationale Operation, die Graphen durchwandern kann.
Man kann mit nativem SQL benötigte Entities effizient in den PersistenceContext laden, bevor man die eigentliche Geschäftslogik ablaufen lässt.
Wenn die Geschäftslogik auf ein Entity zugreift, dass bereits im PersistenceContext ist, muss das Entity nicht erst geladen werden.
Muster #2: Benötigte Entities mit modernem SQL zu suchen und vorzuladen kann deutlich effizienter sein als die Entities einzeln zu laden, wenn die Geschäftslogik darauf zugreift.
Dabei gibt es noch zwei Einschränkungen, die ich im Vortrag nicht erwähnt habe, mittlerweile aber in die aktualisierten Folien eingearbeitet habe:
Der PersistenceContext ist nach dem
@Id-Attribute organisiert. Wenn die Geschäftslogik über andere Attribute darauf zugreift, kann sie vom Cache nicht profitieren.Vor einigen Jahren bin ich dazu über einen Artikel gestoßen, der zeigt, wie man @CacheIndex in EcliplseLink dafür verwenden kann.
Vor dem Ausführen einer nativen Abfrage wird der PersistenceContext ge-flushed. Das kann unerwünschte Nebeneffekte haben.
Daher sollten die Abfragen zum Vor-Laden der Entities am Anfang einer Transaktion stattfinden. Durch Wiederbenutzung vom solchem Code könnte diese Abfrage aber auch in die Mitte eine Transaktion rutschen.
