Stratégie FetchPlan de l'EntityManager

Un plan d'extraction (FetchPlan) est la stratégie utilisée par EntityManager pour extraire des objets associés si l'application doit accéder aux relations.

Exemple

Supposons que votre application comporte deux entités : Service et Employé. La relation entre l'entité Service et l'entité Employé est une relation un à plusieurs bidirectionnelle : un service comporte plusieurs employés et un employé appartient à un seul service. Etant donné que dans la plupart des cas, lorsque l'entité Service est extraite, les employés correspondants doivent être extraits, le type d'extraction de cette relation un à plusieurs sera défini comme EAGER.

Voici un fragment de code de la classe Service (Department).

	@Entity
public class Department {

    @Id
    private String deptId;

    @Basic
    String deptName;

		@OneToMany(fetch = FetchType.EAGER, mappedBy="department", cascade = {CascadeType.PERSIST})
		public Collection<Employee> employees;

}

Dans un environnement réparti, lorsqu'une application appelle em.find(Department.class, "dept1") pour trouver une entité Service avec la clé "dept1", cette opération find retourne l'entité Service et toutes les relations d'extraction hâtive. Dans le cas du fragment de code précédent, il s'agit de tous les employés du service "dept1".

Dans les versions antérieures à WebSphere eXtreme Scale 6.1.0.5, l'extraction d'une entité Service et de N entités Employé provoquait N+1 transferts client-serveur car le client extrayait une entité pour un transfert client-serveur. Vous pouvez améliorer les performances avec l'extraction de ces N+1 entités en un seul transfert.

Plan d'extraction

Un plan d'extraction peut être utilisé pour personnaliser le mode d'extraction des relations hâtives en adaptant la profondeur maximale des relations. La profondeur d'extraction se substitue davantage aux relations hâtives que la profondeur spécifiée pour les relations lentes. Par défaut, la profondeur d'extraction correspond à la profondeur d'extraction maximale, ce qui implique l'extraction des relations hâtives de tous les niveaux pouvant être parcourues hâtivement depuis l'entité racine. Une relation EAGER peut être parcourue hâtivement depuis une entité racine uniquement si toutes les relations en partant de l'entité racine sont configurées comme extraites hâtivement.

Dans l'exemple précédent, l'entité Employé peut être parcourue hâtivement depuis l'entité Service car la relation Service-Employé est configurée comme étant extraite hâtivement.

Si l'entité Employé présente une autre relation hâtive avec une entité Adresse par exemple, cette dernière peut également être parcourue hâtivement depuis l'entité Service. Toutefois, si les relations Service-Employé ont été configurées en mode d'extraction lente, l'entité Adresse ne peut pas être parcourue hâtivement depuis l'entité Service car la relation Service-Employé rompt la chaîne d'extraction hâtive.

Un objet FetchPlan peut être extrait de l'instance EntityManager. L'application peut utiliser la méthode setMaxFetchDepth pour modifier la profondeur d'extraction maximale.

Un plan d'extraction est associé à une instance EntityManager. Le plan d'extraction s'applique à toutes les opérations fetch, tel que décrit ci-dessous de manière plus spécifique.

L'objet FetchPlan est modifiable. Une fois modifiée, la valeur est appliquée aux opérations fetch exécutées ultérieurement.

Un plan d'extraction est important dans un environnement réparti car il décide si les entités de relation d'extraction hâtive sont extraites avec l'entité racine dans un ou plusieurs transferts client-serveur.

En reprenant l'exemple précédent, considérez que la profondeur maximale du plan d'extraction est infinie. Dans ce cas, lorsqu'une application appelle em.find(Department.class, "dept1") pour trouver une entité Service, cette opération find retourne l'entité Service et N entités Employé dans un transfert client-serveur. Toutefois, pour un plan d'extraction doté d'une profondeur d'extraction maximale égale à zéro, seul l'objet Service est extrait du serveur alors que les entités Employé sont extraites du serveur uniquement lors de l'accès à la collection d'employés de l'objet Service.

Plans d'extraction différents

Plusieurs plans d'extraction sont disponibles en fonction de vos besoins ; ils sont détaillés dans les sections suivantes.

Impact sur une grille répartie

Important : Si une relation est demandée, à l'aide de l'annotation ou de la configuration OrderBy, elle est considérée comme une relation hâtive même si elle est configurée comme une extraction lente.

Remarques sur les performances dans un environnement réparti

Par défaut, toutes les relations pouvant être parcourues hâtivement depuis l'entité racine sont extraites en un seul transfert client-serveur. Ce mode de transfert peut améliorer les performances si toutes les relations sont amenées à être utilisées. Toutefois, dans certains scénarios d'utilisation, les relations pouvant être parcourues hâtivement depuis l'entité racine ne sont pas toutes utilisées, ce qui entraîne des frais d'exécution et une sollicitation de la bande passante en raison de l'extraction de ces entités superflues.

Dans ces cas de figure, l'application peut définir la profondeur d'extraction maximale sur une valeur faible afin de réduire la profondeur des entités à extraire en rendant lentes toutes les relations hâtives au-delà de ce niveau de profondeur. Ce paramètre peut améliorer les performances.

En reprenant l'exemple Service-Employé-Adresse précédent, par défaut, toutes les entités Adresse associées aux employés du Service "dept1" sont extraites lorsque em.find(Department.class, "dept1") est appelée. Si l'application n'utilise pas les entités Adresse, elle peut définir la profondeur d'extraction maximale sur 1, de sorte que les entités Adresse ne sont pas extraites avec l'entité Service.