Konkret bedeutet dies, dass eine Menge von Funktionalitäten bzw. Verhaltensweisen per default voreingestellt sind. Dieses Defaultverhalten sollte den Großteil (80–90%) der typischen Anwendungsfälle abdecken. Trifft das Standardverhalten nicht das Anforderungsprofil, dann kann der Entwickler diese Standardwerte bzw. das Standardverhalten leicht übersteuern. Als Beispiel dafür sei angeführt, dass Persistent Entities per default einen Eager Load-Mechanismus verwenden. Will der Entwickler Lazy Load als Fetching-Strategie verwendet haben, muss er dieses explizit angeben.

Detached Objects können durch verschiedene Umstände entstehen, beispielsweise dann, wenn eine Instanz einer Persistent Entity serialisiert wird. In diesem Fall ist die serialisierte Form der Persistent Entity ein Detached Object.

Bei größeren Objektnetzen oder Objektbäumen kann dieser Ansatz in Verbindung mit einer großen Datenmenge schnell zu langen Ladezeiten und hohem Speicherverbrauch durch eine entsprechende Anzahl an gefüllten Objekten führen.

Die Eager Load Fetching-Strategie ist die Standardstrategie, die von der Persistence Provider Runtime angewendet wird, falls keine andere explizite Angabe gemacht wird. Die mögliche Alternative ist Lazy Load.

Es handelt sich hierbei beispielsweise um das Mappen einer Tabelle auf eine Persistent Entity und darin eingebetteter weiterer POJOs (einfacher Java-Klassen), um eine denormalisierte Tabelle auf ein Objektnetz zu projizieren.

Persistent Entity mit dem Mapping auf ein Embeddable Object

 @Entity 
 @Table(name = “KUNDE”) 
 public class Kunde
        implements java.io.Serializable { 
   private int id;
   private Adresse adresse;
   private String name; 
   private String vorname; 

   public Kunde(String name, String vorname,
       String strasse, String stadt) { 
     this.adresse =
         new Adresse(strasse, stadt); 
     this.name= name; 
     this.vorname = vorname; 
   } 
   … 

   @Embedded 
   @AttributeOverrides({ 
     @AttributeOverride(name = “strasse”,
       column = @Column(name = “STRASSE”)), 
     @AttributeOverride(name = “stadt”,
       column = @Column(name = “STADT”)) }) 
   public Adresse getAdresse() { 
     return adresse; 
   } 

   public void setAdresse(
       Adresse adresse) { 
     this.adresse = adresse; 
   } 

   @Column(name = “NAME”) 
   public String getName() { 
     return name; 
   } 

   public void setName(String name) { 
     this.name = name; 
   } 
   …

Embeddable Object

 @Embeddable
 public class Adresse
     implements java.io.Serializable {
   private String strasse;
   private String stadt;
   …
 }

Die Eager Load-Strategie ist innerhalb der Java Persistence API durchweg als Standard voreingestellt. Lazy Load kommt nur dann zur Anwendung, wenn der Entwickler dies explizit angibt. Der Eager Load-Mechanismus ist verpflichtend durch die Hersteller der Persistence Provider Runtimes (z.B. Hibernate) zu implementieren und zur Verfügung zu stellen. Bei Lazy Load ist es zurzeit noch so, dass die Angabe von Lazy Load „lediglich“ als Hinweis für die Persistence Provider Runtime gesehen wird und nicht weiter spezifiziert ist, in welcher konkreten Ausprägung / Umsetzung der Lazy Load-Mechanismus tatsächlich zur Verfügung gestellt und genutzt wird.

Momentan sieht es so aus, dass die Umsetzung des Lazy Load-Mechanismus den Herstellern der Persistence Provider Runtimes obliegt und nicht weiter spezifiziert wird. Dies birgt natürlich eine Menge Gefahren wie beispielsweise eine nicht mögliche Gewährleistung der Interoperabilität durch divergierende architektonische und technische Umsetzungen der Hersteller.

Wie und wo wird die zu verwendende Fetching-Strategie deklariert?

Die Angabe der von der Persistence Provider Runtimes zu verwendenden Fetching-Strategie kann an verschiedenen Elementen im Code erfolgen.

 Attribute

Für jedes persistentes Attribut einer Entität bzw. eines Objektes kann direkt bei den Mapping-Informationen des Attributes die Fetching-Strategie hinterlegt werden. Dazu kann zusätzlich zur @Column-Annotation die Annotation @Basic(fetch=FetchType.LAZY), @Basic(fetch=FetchType.EAGER), @Serialized(fetch=FetchType.LAZY) bzw. @Serialized(fetch=FetchType.EAGER) angegeben werden.

Die Angabe der zu verwendenden Fetching-Strategie auf Attributebene ist optional. Wird bei einem persistenten Attribut keine diesbezügliche Angabe vorgenommen, geht die Persistence Provider Runtime von dem Standardverhalten des Eager Loadings (fetch=FetchType.EAGER) aus.

 Java Persistence QL-Abfragen

Innerhalb von Java Persistence QL-Abfragen besteht die Möglichkeit, in der FROM-Klausel einer Abfrage eine Fetching-Strategie anzugeben. Diese werden als sogenannte „Fetch Joins“ bezeichnet und sind von der Hibernate HQL inspiriert. Fetch Joins werden dafür genutzt, die Beziehungen zwischen einer Entität und deren abhängigen Enitäten bereits beim Ausführen der Java Persistence QL-Abfrage mit aufzulösen und ein Prefetching der abhängigen Entitäten vorzunehmen. Das originäre Resultset enthält nur die Ergebnismenge der primären Abfrage, d.h. die abhängigen Entitäten sind nicht Bestandteil der Ergebnismenge der Abfrage. Bei der Navigation über Objekte aus dieser Ergebnismenge kann jedoch sehr schnell auf deren abhängigen Objekte zugegriffen werden, da diese bereits vorgeladen worden sind.

 Deklaration von Beziehungen

Bei der Deklaration der Beziehung von einer Entität zu einer anderen durch Verwendung einer der Annotationen @OneToOne, @OneToMany, @ManyToOne, @ManyToMany kann als Element jeder dieser Annotationen (fetch=FetchType.LAZY) oder (fetch=FetchType.EAGER) angegeben werden. Diese Angabe sorgt dafür, dass der Entity Manager die referenzierten Objekte entsprechend der gewählten Strategie sofort oder erst auf konkreten Zugriff hin aus der Datenbank liest bzw. lädt.

Die Angabe der zu verwendenden Fetching-Strategie ist optional. Wird das fetch-Element nicht angegeben, geht die Persistence Provider Runtime von dem Standardverhalten des Eager Loadings (fetch=FetchType.EAGER) aus.

Anzumerken ist, dass diese Informationen auch über die Deployment Deskriptoren angegeben werden können. Als Wertigkeitsregel gilt hier, dass die Deklaration mittels XML im Deployment Deskriptor die Deklaration schlägt, die über Annotationen angegeben worden sind.

Ein wichtiges Merkmal der Java Persistence API ist, dass sie für beliebige POJOs verwendet werden kann und nicht (wie früher mit EJB Entity Beans) auf EJBs eingeschränkt ist. Somit steht sie auch den Entwicklern zur Verfügung, die keine EJB-Komponenten in ihren Applikationen benötigen.

Beteiligt sind an der Entwicklung die führenden Persistenzexperten aus dem Hibernate-, TopLink- und JDO-Lager.

Zurzeit wird Lazy Load ausschließlich in der physikalischen Schicht umgesetzt, in der sich auch der Entity Manager in der Persistence Provider Runtime befindet. Dies wird für gewöhnlich der Server sein. Daher ist auf Client-Seite kein Lazy Load-Mechanismus möglich. Dies hat drei Konsequenzen:

1. Der Zugriff eines Clients auf ein nicht geladenes Attribut eines mittels Lazy Load geladenen Detached Objects führt zu einer Exception.

2. Der zuvor beschriebene Zugriff führt eben nicht dazu, dass das Attribut aus der Datenbank geladen wird, da das Detached Object nicht mehr vom Entity Manager (der sich auf dem Server befindet) verwaltet wird, also kein Managed Object mehr ist.

3. Desweiteren werden nicht geladene Assoziationen bei dem Zugriff auf ein Detached Object nicht nachgeladen. Der Grund dafür ist analog dem zuvor angeführten Grund.

Logisches Geschäftsobjekt (Persistent Entity), bestehend aus drei Tabellen

 @Entity
 @Table(name = “KUNDE”)
 @SecondaryTables({
 @SecondaryTable(name = “ADRESSE”)
 @SecondaryTable(name = “TYP”) })
 public class Kunde
     implements java.io.Serializable {
    private int id;
    // Aus Tabelle “KUNDE”
    private String name;
    // Aus Tabelle “KUNDE”
    private String vorname ;
    // Aus Sekundärtabelle “ADRESSE”
    private String strasse;
    …

    // Aus der Haupttabelle “Kunde”
    @Column(name = “NAME”)  
    public String getName() {
      return name;
    }
    …

    // Aus der Sekundärtabelle “ADRESSE”
    @Column(name = “STRASSE”,
        table = “ADRESSE”)
    public String getStrasse() {
      return strasse;
    }
    …

    // Per Default wird, wenn kein @Column
    // angeben ist, davon ausgegangen,
    // dass der Spaltenname gleich dem
    // Attributnamen ist.
    public String getVorname() {
      return vorname ;
    }
 }