Le gestionnaire d’entités JPA doit-il être fermé?

J’ai la méthode ci-dessous.

public Profile readUser(Ssortingng email){ EntityManager em = EMF.get().createEntityManager(); return em.find(Profile.class, email); } 

L’utilisation du gestionnaire d’entités ci-dessus est-elle correcte? Ou il est nécessaire de fermer em? Des suggestions s’il vous plaît.

Je suppose que la réponse est: cela dépend .

Votre gestionnaire d’entités est la clé pour accéder au contexte dans lequel résident les entités. Si votre application est une application JSE, vous devez déterminer quelle est l’espérance de vie de votre contexte.

Considérons que vous créerez un gestionnaire d’entités par requête de l’utilisateur. Ainsi, pendant que vous assistez à une demande donnée, vous gardez votre gestionnaire d’entités ouvert et lorsque vous en avez terminé, vous le fermez.

Dans une application JSE, vous avez peut-être considéré que vous souhaitiez garder votre gestionnaire d’entités ouvert toute la durée de vie de l’application (en supposant que vous ne traitiez pas de grandes quantités de données), puis la fermer lorsque votre application est fermée.

En bout de ligne, quand vous l’ouvrez et quand vous fermez dépend entièrement de votre stratégie et de votre conception. Vous le fermez lorsque vous n’avez plus besoin des entités dans son contexte.

Dans votre exemple, cela n’est pas évident, mais puisque vous créez l’EM dans la méthode, vous devriez la fermer avant de la renvoyer, sinon vous n’y aurez plus access (sauf si vous la conservez dans un registre, pas évident dans le code).

Si vous ne le fermez pas, vos entités seront conservées telles que jointes, même après leur utilisation. Votre contexte sera maintenu en vie même si vous ne pouvez plus accéder à votre EM.

La spécification JPA contient plus de détails. Dans la section 7.7 Contextes de persistance gérée par application, il est dit:

Lorsqu’un gestionnaire d’entités gérées par application est utilisé, l’application interagit directement avec la fabrique de gestionnaires d’entités du fournisseur de persistance pour gérer le cycle de vie du gestionnaire d’entités et pour obtenir et détruire les contextes de persistance.

Tous ces contextes de persistance gérés par application sont étendus et peuvent couvrir plusieurs transactions.

La méthode isOpen et les méthodes isOpen close et isOpen permettent de gérer le cycle de vie d’un gestionnaire d’entités géré par l’application et son contexte de persistance associé.

Le contexte de persistance étendu existe à partir du moment où le gestionnaire d’entités a été créé à l’aide d’ EntityManagerFactory.createEntityManager jusqu’à ce que le gestionnaire d’entités soit fermé au moyen d’ EntityManager.close .

Un contexte de persistance étendu obtenu à partir du gestionnaire d’entités gérées par l’application est un contexte de persistance autonome qu’il ne propage pas avec la transaction.

[…] La méthode EntityManager.close ferme un gestionnaire d’entités pour libérer son contexte de persistance et d’autres ressources. Après avoir appelé close, l’application ne doit plus invoquer d’autres méthodes sur l’instance getTransaction à l’exception de getTransaction et isOpen , ou la getTransaction isOpen sera lancée. Si la méthode close est appelée lorsqu’une transaction est active, le contexte de persistance rest géré jusqu’à la fin de la transaction.

La méthode EntityManager.isOpen indique si le gestionnaire d’entités est ouvert. La méthode isOpen renvoie true jusqu’à la fermeture du gestionnaire d’entités. Pour bien comprendre comment cela fonctionne, il est essentiel de comprendre la relation entre le gestionnaire d’entités et le contexte.

Ainsi, comme vous pouvez le constater, le gestionnaire d’entités est l’interface publique par laquelle vous accédez à vos entités. Cependant, vos entités résident dans un contexte, rattaché à votre gestionnaire d’entités. Comprendre le cycle de vie des différents types de contextes répondra à votre question.

Les contextes de persistance peuvent être de différents types. Dans les applications Java EE, vous pouvez avoir un contexte de persistance de scope de transaction ou un contexte de persistance étendue . Dans l’application JSE, la nature du contexte est contrôlée par le développeur .

Lorsque vous demandez une entité à votre gestionnaire d’entités, celle-ci recherche l’entité dans son contexte attaché, si elle y trouve l’entité, elle la renvoie, sinon elle extrait l’entité de la firebase database. Les appels suivants pour cette entité en contexte renverront la même entité.

Portée des transactions

Dans une application Java EE utilisant le contexte de persistance à scope de transaction, lorsque vous accédez pour la première fois à votre gestionnaire d’entités, il vérifie si la transaction JTA en cours comporte un contexte, si aucun contexte n’est encore présent, un nouveau contexte est créé. lié à ce contexte. Ensuite, l’entité est lue dans la firebase database (à partir du cache si présent) et elle est placée dans le contexte. Lorsque votre transaction se termine (validation ou annulation), le contexte devient invalide et les entités qui le composent se détachent. C’est le scénario classique pour les sessions sans état.

 @PersistenceContext(unitName="EmplService") EntityManager em; 

Cela signifie également que, selon la manière dont vous concevez vos transactions, vous pouvez vous retrouver avec plusieurs contextes.

Contexte de persistance étendue

Dans une application Java EE avec des beans session dynamics, vous pouvez souhaiter que le contexte survienne à plusieurs invocations de beans, puisque vous n’aimerez pas vous engager tant que le bean n’a pas été marqué pour suppression, non? Dans ces cas, vous devez utiliser un contexte de persistance étendu. Dans ce cas, le contexte de persistance est créé lorsqu’il est nécessaire pour la première fois, mais il ne deviendra pas invalide tant que vous n’aurez pas supprimé le bean statefull.

 @PersistenceContext(unitName="EmplService", type=PersistenceContextType.EXTENDED) 

Cela signifie que, quelle que soit l’instance du gestionnaire d’entités injectée dans ce bean dans les appels suivants des méthodes de beans session session statefull, vous pouvez être sûr que vous accéderez toujours au même contexte, et donc même les appels ultérieurs renverront le même par exemple, car c’est le même contexte.

De plus, vos modifications ne seront pas effacées tant que le haricot ne sera pas supprimé ou que vous les viderez manuellement.

Géré par l’application

Vous pouvez toujours instancier manuellement la fabrique de votre gestionnaire d’entités et votre gestionnaire d’entités. C’est ce que vous feriez généralement dans une application JSE, n’est-ce pas?

Pour ce type d’applications, vous n’avez généralement pas de conteneur pour gérer les transactions JTA, n’est-ce pas? Vous utilisez donc des transactions locales de ressources et vous êtes responsable de la validation ou de la restauration manuelle des modifications.

Pour ce type d’application, lorsque vous instanciez votre gestionnaire d’entités, un contexte lui est automatiquement associé.

Selon votre application, vous pouvez décider de créer un gestionnaire d’entités global dont le cycle de vie est associé à la durée de vie de l’application elle-même. C’est-à-dire un gestionnaire d’entités unique pour toute la durée de vie de l’application. Dans ce cas, votre contexte sera créé et détruit avec votre gestionnaire d’entités.

Vous pouvez également créer un gestionnaire d’entités par conversation (transaction) avec votre utilisateur de l’application. La scope dans ce cas est déterminée par vous, mais votre contexte sera créé et détruit avec votre gestionnaire d’entités.