Remarques sur la programmation de chargeurs JPA

Un chargeur Java Persistence API (JPA) est une implémentation de plug-in Loader qui utilise JPA pour interagir avec la base de données. Utilisez les considérations ci-après lorsque vous développez une application qui utilise un chargeur JPA.

Entité eXtreme Scale et entité JPA

Vous pouvez désigner une classe POJO comme une entité eXtreme Scale à l'aide d'annotations d'entité eXtreme Scale et/ou d'une configuration XML. Vous pouvez également désigner la même classe POJO comme une entité JPA à l'aide d'annotations d'entité JPA et/ou d'une configuration XML.

Entité eXtreme Scale : Une entité eXtreme Scale représente les données persistantes stockées dans des mappes ObjectGrid. Un objet d'entité est converti en un nuplet de clé et un nuplet de valeur, qui sont ensuite stockés sous forme de paires de clé/valeur dans les mappes. Un nuplet est un tableau d'attributs de primitive.

Entité JPA : Une entité JPA représente les données persistantes stockées automatiquement dans une base de données relationnelle à l'aide de la persistance gérée par conteneur. Les données sont conservées sous forme de système de stockage de données au format approprié, tel que des nuplets de base de données dans une base de données.

Lorsqu'une entité eXtreme Scale est conservée, ses relations sont stockées dans d'autres mappes d'entités. Par exemple, si vous stockez une entité Consumer avec une relation one-to-many dans une entité ShippingAddress et que l'élément cascade-persist est activé, l'entité ShippingAddress est stockée dans la mappe shippingAddress au format de nuplet. Si vous stockez une entité JPA, les entités JPA associées le sont également dans des tables de base de données lorsque l'élément cascade-persist est activé. Lorsqu'une classe d'objet Java simple est désignée à la fois comme une entité eXtreme Scale et une entité JPA, les données peuvent être stockées à la fois dans des bases de données et des mappes d'entités ObjectGrid. Voici les scénarios les plus courants :
  • Scénario de préchargement : Une entité est chargée à partir d'une base de données à l'aide d'un fournisseur JPA et conservée dans des mappes d'entités ObjectGrid.
  • Scénario de chargeur : Une implémentation de chargeur est intégrée pour les mappes d'entités ObjectGrid de sorte qu'une entité stockée dans des mappes d'entités ObjectGrid puisse être stockée dans une base de données ou chargée à partir de cette dernière, à l'aide de fournisseurs JPA.

Il est également courant qu'une classe POJO soit désignée comme une entité JPA uniquement. Dans ce cas, les mappes ObjectGrid contiennent les instances d'objet Java simple au lieu des nuplets d'entité, dans le cas des entités ObjectGrid.

Considérations liées à la conception d'applications pour les mappes d'entités

Lorsque vous intégrez une implémentation dans une interface JPALoader, les instances d'objet sont directement stockées dans les mappes ObjectGrid.

Toutefois, lorsque vous intégrez une implémentation dans un plug-in JPAEntityLoader, la classe d'entité est désignée à la fois comme entité eXtreme Scale et entité JPA. Dans ce cas, traitez cette entité comme si elle possédait deux stockages de persistance : les mappes d'entités ObjectGrid et le stockage de persistance JPA. L'architecture devient plus compliquée que dans le cas de l'interface JPALoader.

Pour plus d'informations sur le plug-in JPAEntityLoader et les considérations de conception d'application, voir les Plug-in JPAEntityLoader. Ces informations peuvent également vous aider si vous prévoyez d'implémenter votre propre chargeur pour les mappes d'entités.

Considérations sur les performances

Assurez-vous de bien définir le type d'extraction accélérée ou différée approprié pour les relations. Par exemple, une relation bidirectionnelle one-to-many entre Consumer et ShippingAddress, avec OpenJPA pour expliquer les différences de performances. Dans cet exemple, une requête JPA tente select o from Consumer o where . . . d'effectuer un chargement en bloc et charge tous les objets ShippingAddress associés. Voici une relation one-to-many définie dans la classe Consumer :

@Entity
public class Consumer implements Serializable {

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

Voici la relation many-to-one consumer définie dans la classe ShippingAddress :

@Entity
public class ShippingAddress implements Serializable{

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

Si les types d'extraction des deux relations sont configurés avec la valeur eager, OpenJPA utilise N+1+1 requêtes pour extraire tous les objets Consumer et ShippingAddress, N représentant le nombre d'objets ShippingAddress. Toutefois, si l'adresse de livraison est modifiée pour utiliser une extraction de type différé comme ci-après, il ne faut que deux requêtes pour extraire toutes les données.

@Entity
public class ShippingAddress implements Serializable{

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

La requête renvoie les mêmes résultats, mais le nombre inférieur de requêtes permet de réduire considérablement l'interaction avec la base de données, ce qui peut améliorer les performances de l'application.