Professional Documents
Culture Documents
Cédric BOTTERO
Michaël MATHIEU
• Lorsqu’un client appelle l’EJB, une instance de ce dernier est créée, puis
sert le client. Cette instance reste disponible pour les futurs appels de ce
client uniquement. Cette instance sera détruite à la fin de la session
(timeout ou appel à une méthode portant l’annotation @Remove)
• S’il y a trop d’instances d’un EJB en mémoire, ces dernières peuvent être
sorties de la mémoire de travail. Elles passent ainsi en mode passif (=
sauvées sur disque => tous les attributs doivent être sérialisables = types
implémentant l’interface Serializable)
Sérialisation
• Le type des attributs et le type de retour de chaque méthode doivent être
Serializable (sauf dans le cas d’une méthode d’un EJB stateless local)
• Par précaution, nous tâcherons de veiller à ce que tous les types que nous
utilisons soient Serializable
• Le serialVersionUID permet de faire la distinction entre des objets de
même type, mais d’une version différente
• Lorsque qu’un objet est reçu, le destinataire vérifie que le serialVersionUID
de l’objet reçu correspond à celui de la classe qu’il a chargé. S’il diffère, une
InvalidClassException est lancée
• Ce mécanisme permet de s’assurer que l’émetteur et le destinataire travaillent
avec la même version de l’objet
• Cette solution a une faiblesse: lors d’une modification, elle nécessite que toutes
les applications qui utilisent cette classe doivent être mis à jour, alors que cela
n’est pas forcément nécessaire. En effet, dans le cas où on ajoute un nouvel
attribut à un objet, cela ne signifie pas forcément que toutes les applications ont
l’utilité de ce nouvel attribut…
=> on donne une valeur arbitraire par défaut au serialVersionUID et on ne
la modifie pas
Local vs. Remote
• Permet de spécifier la manière d’accéder à l’EJB =>
l’implémentation des services est identique
• Local
≠ appel à un EJB se trouvant sur la même machine
= appel à un EJB se trouvant dans la même JVM
• Remote
– utilise RMI (Remote Method Invocation) (=> plus lent
qu’un appel local) et JNDI (Java Naming and Directory
Interface)
– utilisé dans la majorité des cas
Local
EJB 2
Local
EJB 2
Local
EJB 2
META-INF/jboss.xml
Local
EJB 2
Local
EJB 2
META-INF/jboss.xml
Local
EJB 2
Local
EJB 3
Entity
• Permet de gérer la persistance comme le ferait
Hibernate sur le concept de object-relational
mapping (ORM) => illusion de travailler avec une
base de données objet
• Le mapping ne se fait plus forcément dans un
fichier XML (comme hibernate.cfg.xml),
mais directement dans le code avec des
annotations (@Id, @Column, etc.)
• D’avantage de détails dans le dernier chapitre de
ce cours « Persistance avec JPA »
Message-Driven
• Permet à des applications de communiquer entre elles, en étant faiblement
couplées, et de manière asynchrones
• Ce concept est connu sous le nom de Message-oriented middleware (MOM)
• Les produits implémentant ce mécanisme sont nombreux comme IBM
WebSphere MQ (anciennement MQSeries), JBoss Messaging (qui remplacera
JBoss MQ), etc.
• Cohérence
Après qu’une transaction se soit réalisée, le base de données ou le système doit se trouver
dans un état cohérent
• Isolation
Une transaction doit se réaliser sans dépendre des autres transactions qui peuvent avoir
lieu en même temps
• Durabilité
Lorsqu’une transaction s’est terminée, le résultat de cette dernière est durable : que la
transaction ait été annulée ou qu’elle se soit terminée correctement, les opérations qu’elle
a effectué ne doivent pas disparaître
@Transient
• Permet de spécifier qu’il ne faut pas persister un attribut
donné
Persistance avec JPA
@Id
• Permet de définir quel champ sera utilisé comme clé primaire
• @OneToMany
• @ManyToOne
• @ManyToMany
ORM
ORM
ORM
ORM
• Inconvénients des annotations, surtout dans le cas de la
persistance JPA :
– Dégrade la lisibilité du code
– Perte de la séparation entre Entité et Mapping
– En cas de modification, nécessite de recompiler les classes modifiées,
au lieu de juste modifier les fichiers de mapping concernés
=> à utiliser plutôt dans le cas d’un prototype
• Solution plus élégante : utilisation d’un fichier de mapping XML
(META-INF\orm.xml) (contenu sur les slides suivant)
orm.xml (1/2)
orm.xml (2/2)
Héritage
• Avec JPA, il est également possible d’avoir une notion
d’héritage entre les entités
• Le développeur doit choisir la manière dont seront stockées les
informations (@Inheritance(strategy= ...)):
– une seule table (InheritanceType.SINGLE_TABLE)
– plusieurs tables liées (InheritanceType.JOINED)
– des tables indépendantes
(InheritanceType.TABLE_PER_CLASS)
• Pour d’avantage de précisions, nous vous renvoyons à la page
284 du livre « EJB 3 in Action », 2007, Manning +
http://en.wikibooks.org/wiki/Java_Persistence/Inheritance
Callbacks
• Comme pour les EJB session et les Message-Driven, il existe
des callbacks pour le Entity
• Avant / après la persistance d’une Entity (@PrePersist /
@PostPersist)
• Après avoir chargé une Entity lors d’une requête ou d’un
refresh (@PostLoad)
• Avant / après la mise à jour d’une Entity (@PreUpdate /
@PostUpdate)
• Avant / après la suppression d’une Entity (@PreRemove /
@PostRemove)
Références
• EJB 3 in action, 2007, Manning
• JBoss in action, 2009, Manning