Consideraciones de programación del cargador JPA

Un cargador Java Persistence API (JPA) es una implementación de plug-in de cargador que utiliza JPA para interactuar con la base de datos. Utilice las siguientes consideraciones cuando desarrolle una aplicación que utiliza un cargador JPA.

Entidad eXtreme Scale y entidad JPA

Puede designar cualquier clase POJO como una entidad eXtreme Scale utilizando las anotaciones de entidad eXtreme Scale, la configuración XML, o ambos. También puede designar la misma clase POJO como entidad JPA mediante el uso de anotaciones de entidad JPA o de la configuración de XML.

Entidad eXtreme Scale: una entidad eXtreme Scale representa los datos persistentes almacenado en correlaciones de ObjectGrid. Un objeto de entidad se transforma en un tuple de clave y un tuple de valor, que después de almacenan como pares de clave-valor en las correlaciones. Un tuple es una matriz de atributos primitivos.

Entidad JPA: una entidad JPA representa los datos persistentes almacenados en una base de datos relacional que utiliza automáticamente la persistencia gestionada por contenedor. Los datos persisten en alguna forma de sistema de almacenamiento de datos con el formato adecuado como ,por ejemplo, los tuples de base de datos.

Cuando persiste una entidad eXtreme Scale, sus relaciones se almacenan en otras correlaciones de entidad. Por ejemplo, cuando se persiste una entidad Consumer con una relación de uno a muchos con una entidad ShippingAddress, si el valor cascade-persist está habilitado, la entidad ShippingAddress se almacena en la correlación shippingAddress en formato de tuple. Si persiste una entidad JPA, las entidades JPA relacionadas también se persisten en las tablas de base de datos, si el valor cascade-persist está habilitado. Cuando se designa una clase POJO como una entidad eXtreme Scale y, también, una entidad JPA, los datos se pueden persistir tanto en correlaciones, como en bases de datos de la entidad ObjectGrid. Los usos comunes son los siguientes:
  • Escenario de precarga: se carga una entidad desde una base de datos utilizando un proveedor JPA y se conserva en las correlaciones de entidad ObjectGrid.
  • Escenario de cargador: se conecta una implementación de cargador para las correlaciones de la entidad ObjectGrid, de forma que una entidad almacenada en las correlaciones de la entidad ObjectGrid se puede conservar o cargar desde una base de datos utilizando los proveedores JPA.

También es habitual que una clase POJO se designe únicamente como entidad JPA. En ese caso, lo que se almacena en las correlaciones ObjectGrid son las instancias POJO, frente a los tuples de entidad si se tratara de entidades ObjectGrid.

Consideraciones sobre el diseño de aplicaciones en correlaciones de entidad

Cuando conecta una interfaz JPALoader, las instancias de objeto se almacenan directamente en las correlaciones de ObjectGrid.

Sin embargo, cuando se conecta un JPAEntityLoader, la clase de entidad se designa como entidad eXtreme Scale y, también como una entidad JPA. En este caso, trate a esta entidad como si tuviera dos almacenes persistentes: las correlaciones de entidad ObjectGrid y el almacén de persistencia JPA. La arquitectura es más compleja que el caso de JPALoader.

Si desea más información sobre el plug-in JPAEntityLoader y las consideraciones de diseño de la aplicación, consulte Plug-in JPAEntityLoader. Esta información también puede ayudarle si tiene previsto implementar su propio cargador para las correlaciones de entidad.

Consideraciones sobre el rendimiento

Asegúrese de que establece el tipo Fetch en EAGER o LAZY para las relaciones. Por ejemplo, una relación Consumer bidireccional de uno a muchos con ShippingAddress, con OpenJPA para ayudar a explicar las diferencias en el rendimiento. En este ejemplo, una consulta JPA intenta select o from Consumer o where . . . para realizar una carga masiva, y también carga todos los objetos ShippingAddress relacionados. Una relación de uno a muchos se define en la clase Consumer del modo siguiente:

@Entity
public class Consumer implements Serializable {

    @OneToMany(mappedBy="consumer",cascade=CascadeType.ALL, fetch =FetchType.EAGER) 
    ArrayList <ShippingAddress> addresses;

A continuación, se muestra el consumidor de una relación de muchos a uno definida en la clase ShippingAddress:

@Entity
public class ShippingAddress implements Serializable{

    @ManyToOne(fetch=FetchType.EAGER)
    Consumer consumer;
}

Si los tipos Fetch de ambas relaciones se configuran como eager, OpenJPA utiliza las consultas N+1+1 para obtener todos los objetos Consumer y objetos ShippingAddress, donde N es el número de objetos ShippingAddress. Sin embargo, si se modifica el ShippingAddress para utilizar el tipo Fetch LAZY del modo siguiente, sólo toma dos consultas para obtener todos los datos.

@Entity
public class ShippingAddress implements Serializable{

    @ManyToOne(fetch=FetchType.LAZY)
    Consumer consumer;
}

Aunque la consulta devuelve los mismos resultados, tener un número inferior de consultas reduce de forma significativa la interacción con la base de datos, que puede aumentar el rendimiento de la aplicación.