Ein JPA-Loader (Java Persistence API (JPA)) ist eine Loader-Plug-in-Implementierung, die JPA für die Interaktion mit der Datenbank verwendet. Verwenden Sie die folgenden Hinweise, wenn Sie eine Anwendung entwickeln, die einen JPA-Loader verwendet.
Sie können eine beliebige POJO-Klasse über eXtreme-Scale-Annotationen und/oder XML-Konfiguration als eXtreme-Scale-Entität festlegen. Dieselbe POJO-Klasse kann über JPA-Entitätsannotationen und/oder XML-Konfiguration auch als JPA-Entität festgelegt werden.
eXtreme-Scale-Entität: Eine eXtreme-Scale-Entität stellt persistente Daten dar, die in ObjectGrid-Maps gespeichert werden. Ein Entitätsobjekt wird in ein Schlüsseltupel und ein Werttupel umgesetzt, die dann als Schlüssel/Wert-Paar in den Maps gespeichert werden. Ein Tupel ist eine Sammlung primitiver Attribute.
JPA-Entität: Eine JPA-Entität stellt persistente Daten dar, die über Container-managed Persistence (CMP) automatisch in einer relationalen Datenbank gespeichert werden. Die Daten werden in Form eines Datenspeichersystems entsprechenden Formats persistent gespeichert, z. B. als Datenbanktupel in einer Datenbank.
Es ist auch gängig, dass eine POJO-Klasse nur als JPA-Entität definiert wird. In diesem Fall werden POJO-Instanzen in den ObjectGrid-Maps gespeichert und keine Entitätstupel, wie es bei einer ObjectGrid-Entität der Fall ist.
Wenn Sie eine JPALoader-Schnittstelle integrieren, werden die Objektinstanzen direkt in den ObjectGrid-Maps gespeichert.
Wenn Sie jedoch ein JPAEntityLoader-Plug-in integrieren, wird die Entitätsklasse sowohl als eXtreme-Scale-Entität als auch als JPA-Entität definiert. In diesem Fall behandeln Sie diese Entität so, als hätte sie zwei persistente Speicher: die ObjectGrid-Entitäts-Maps und den JPA-Persistenzspeicher. Die Architektur wird komplexer als beim JPALoader-Plug-in.
Weitere Einzelheiten zum JPAEntityLoader-Plug-in sowie Hinweise zum Anwendungsdesign finden Sie in JPAEntityLoader-Plug-in. Diese Informationen können auch helfen, wenn Sie planen, einen eigenen Loader für die Entitäts-Maps zu implementieren.
Stellen Sie sicher, dass Sie den richtigen Abruftyp (eager oder lazy) für Beziehungen festlegen. Die Leistungsunterschiede lassen sich beispielsweise an einer bidirektionalen 1:n-Beziehung zwischen "Consumer" und "ShippingAddress" mit OpenJPA besser erklären. In diesem Beispiel versucht eine JPA-Abfrage mit select o from Consumer o where . . . einen Massenladevorgang durchzuführen und auch alle zugehörigen ShippingAddress-Objekte zu laden. Im Folgenden sehen Sie eine 1:n-Beziehung, die in der Klasse "Consumer" definiert ist:
@Entity
public class Consumer implements Serializable {
@OneToMany(mappedBy="consumer",cascade=CascadeType.ALL, fetch =FetchType.EAGER)
ArrayList <ShippingAddress> addresses;
Im Folgenden sehen Sie eine n:1-Beziehung, die in der Klasse "ShippingAddress" definiert ist:
@Entity
public class ShippingAddress implements Serializable{
@ManyToOne(fetch=FetchType.EAGER)
Consumer consumer;
}
Wenn die Abruftypen beider Beziehungen mit eager definiert sind, verwendet OpenJPA N+1+1-Abfragen, um alle Consumer-Objekte und ShippingAddress-Objekte abzurufen, wobei N für die Anzahl der ShippingAddress-Objekte steht. Wird das ShippingAddress-Objekt jedoch geändert, so dass, wie im folgenden Beispiel gezeigt, der Abruftyp "lazy" verwendet wird, werden nur zwei Abfragen zum Abrufen aller Daten benötigt:
@Entity
public class ShippingAddress implements Serializable{
@ManyToOne(fetch=FetchType.LAZY)
Consumer consumer;
}
Obwohl die Abfrage in beiden Fällen dieselben Ergebnisse zurückgibt, nimmt mit einer geringeren Anzahl an Abfragen die Interaktion mit der Datenbank erheblich ab, was die Anwendungsleistung steigern kann.