JPA

- Mise à jour : 09/06/2015 - Copyright(C) 2015 - Laurent Chrétien

- L'entity bean, l'entity manager - pp : 13/03/2015 - dm : 08/06/2015
- Cash. Bean Managé. Merge - pp : 08/06/2015 - dm : 08/06/2015
- Factory. Persistence.xml - pp : 08/06/2015 - dm : 08/06/2015
- Transaction - pp : 09/06/2015 - dm : 09/06/2015


L'ENTITY BEAN, L'ENTITY MANAGER

Révisions : 2015 - 13/03, 11/03, 08/06

L'entity bean

L'entity bean, le pojo, est l'enregistrement ramené à sa plus simple expression, la plus épurée, à l'ancienne, juste les champs et les setters et getters. Aucune autre méthode.

C'est un élément réellement fondamental, au sein de toute application. Toute application gère fondamentalement des données et le bean entité en est la matérialisation constante, unique et parfaite.

Dans la modèlisation N-tiers, désormais incontournable, où toute application se trouve décomposée systématiquement en services spécialisés indépendants fortement génériques, s'échangeant des flux de données, le bean de donnée est l'unité de ce flux. Son caractère générique est la base même de la généricité des services.

L'entity manager

C'est très précisément et pleinement ce qui se passe avec JPA, et rend sa syntaxe infiniment simple, quelle que soit la donnée.

Tout est en effet basé sur l'analyse dynamique du bean de données standard par introspection (objet Class de l'instance donnant les méthodes et les champs, et possibilité complète de les appeler et de les valoriser).

monEntityManager.persist(monBeanDeDonnee) suffit pour écrire n'importe quel bean dans la base de données. Un vrai "miracle". On ne fera plus jamais mieux !

Idem pour la recherche avec la méthode find(identifiant, MonBeanClasse.class).

CASH. BEAN MANAGE. MERGE.

Révisions : 2015 - 08/06

Les entités persistée ou lues deviennent suivies, "managées".

Leurs modifications éventuelles sont tracées et mémorisées de façon transparente, "invisible".

Ceci en prévision de l'écriture optimisée automatique dans la base de données (génération des ordres SQL effectivement nécessaires lors du flush() ).

Le manager joue donc le rôle de cash. Les modifications sont très rapides. Elles ne donnent pas lieu à un échange avec la base de données, tant que le flush n'est pas lancé.

Lorque le manager est fermé, ce suivi automatique cesse. Ses beans deviennent alors "détachés".

Pour mettre à jour dans la base une entité existant dans cette base, mais détaché, et donc dans le cadre d'un nouveau manager, on utilisera la méthode merge() et non plus persist() réservée à l'ajout une nouvelle entité.

FACTORY, PERSISTENCE.XML

Révisions : 2015 - 08/06

Un manager d'entité est créé par une factory. C'est une opération fréquente et rapide.

La création de la factory elle, par contre, n'est pas rapide. Elle se réalise à partir de la description de connection jdbc à la base de données présente dans le fichier persistence.xml.

Cette description s'appelle une unité (de base données). Elle a un identifiant, qui est utilisé lors de création de la factory.

Quand on travaille avec des ejb de session, la création de la factory et celle du manager sont cachées, transparentes. Le manager est injecté automatiquement dans le bean, simplement disponible.

Ceci allège fortement l'écriture et permet en outre de laisser l'outil se charger des opérations transactionnelles éventuellement complexes.

TRANSACTION

Révisions : 2015 - 09/06

Pour simplement lire une ou des entités on n'a pas besoin d'une transaction. Le connection à la base de données n'est maintenue que le temps de l'opération. C'est transparent.

Pour écrire (persist, merge, delete) si.

Sous java SE

Sous java SE (hors ejb), on active une transaction avec beginTransaction(). Il y a alors connection effective avec la base de données et ouverture de la transaction. Un connection jdbc est effectivement demandée et maintenue jusqu'au commit.

L'idée est toujours, dans ce cas qui est de loin le plus courant, pratiqué et standard, d'avoir une transaction, un accès réel à la base de données, le plus court possible.

Bean de session. Cas courant.

Avec les ejb de session, par défaut l'entité manager injecté est aussi refabriqué pour chaque appel de méthode qui en a besoin. Par défaut également, et donc sauf spécification contraire, la méthode est de type transactionnelle. La transaction se termine en fin de méthode et le manager disparait avec elle. Il est donc attaché à la transaction et dure autant qu'elle. (Transaction Scoped). A la sortie de la méthode les entites deviennent détachées.

Manager à portée "étendue"

Avec les ejb de session, et plus précisément ceux avec état ("stateful"), et dans ce cadre uniquement, on a aussi le droit cependant de déclarer éventuellement le manager comme "étendu", (extended). Il reste alors ouvert et conservé d'un appel à l'autre, aussi longtemps que le bean est lui même actif.

Il n'y a alors qu'une simulation, "en cash", des ces opérations d'écriture. On réservera leur concrétisation par flush et commit à une méthode déclarée comme transactionnelle (@Transactional), dans laquelle le manager sera réellement couplé à une transaction.

Ce sera typiquement la méthode de validation de la saisie faite par l'utilisateur et celle correspondant aussi à la fin de l'échange, de la "conversation", et du bean de session.

Ce n'est pas l'usage le plus fréquent. De façon génerale, on préfère que toutes les opérations de modification de la base soient concentrées explicitement dans une seule méthode.