8. Transaction gérée par le serveur

8.1. Introduction

Dans ce cas, les transactions ne sont pas gérées manuellement mais par le serveur. Il n'est pas légal d'injecter la transaction dans l'EJB comme dans le cas précédent. On peut toutefois contrôler le contexte transactionnel par annotations, comme nous allons le voir.

8.2. Déclaration du mode transactionnel

Le mode transactionnel se déclare de la même façon, en changeant la valeur de l'attribut passé à l'annotation @TransactionManagement.

Exemple 71. Annotation sur un EJB en mode container managed transaction

@Stateless(mappedName="MarinService")
 @Remote(MarinService.class)
 @TransactionManagement(TransactionManagementType.CONTAINER)
 public  class MarinServiceImpl  implements MarinService {

     // reste de la classe
}

Notons que ce mode est le mode par défaut, cette annotation est donc optionnelle.

8.3. Gestion de la transaction

Dans ce mode, le fait d'entrer dans une méthode métier démarre automatiquement une transaction. C'est en tout cas le comportement par défaut. On peut modifier ce comportement en annotant chaque méthode métier individuellement, ou la classe de l'EJB, auquel cas toutes les méthodes métier partageront le même comportement. L'annotation qui permet de gérer ce comportement est @TransactionAttribute. Elle ne prend qu'un seul attribut, de type TransactionAttributeType. Cette énumération peut prendre les valeurs suivantes : MANDATORY, NEVER, NOT_SUPPORTED, REQUIRED, REQUIRES_NEW et SUPPORTS. Annoter une méthode de cette façon a trois conséquences.

Cela indique au serveur d'application ce qu'il doit faire : créer une nouvelle transaction ou pas, récupérer une transaction existante, etc...
Cela indique le comportement que le serveur doit avoir lorsqu'une méthode d'un EJB est invoquée par un client qui se trouve déjà dans un contexte transactionnel, comme une méthode d'un autre EJB par exemple.
Cela indique enfin la valeur de la transaction que le resource manager va avoir en référence.

Résumons ces différents comportements dans le tableau suivant. Dans ce tableau, T1 représente la transaction dans laquelle se trouve le client, si elle existe. T2 représente une nouvelle transaction, créée par le serveur d'application pour l'exécution de la méthode métier appelée.

Tableau 1. Valeurs de l'attribut de @TransactionAttribute

Valeur de l'attribut	Transaction dans laquelle se trouve le client	Transaction dans laquelle se trouve la méthode métier	Transaction enregistrée auprès du resource manager
NOT_SUPPORTED	pas de transaction	aucune	`null`
NOT_SUPPORTED	`T1`	aucune	`null`
REQUIRED	pas de transaction	`T2`	`T2`
REQUIRED	`T1`	`T1`	`T1`
SUPPORTS	pas de transaction	aucune	`null`
SUPPORTS	`T1`	`T1`	`T1`
REQUIRES_NEW	pas de transaction	`T2`	`T2`
REQUIRES_NEW	`T1`	`T2`	`T2`
MANDATORY	pas de transaction	ERREUR	-
MANDATORY	`T1`	`T1`	`T1`
NEVER	pas de transaction	aucune	`null`
NEVER	`T1`	ERREUR	-

8.4. Fonctionnement de la transaction

Il n'y a rien besoin de faire pour gérer la transaction dans ce cas. Toutes les étapes du cycle de vie de cette transaction sont gérées par le serveur d'application.

8.5. Remarques

L'utilisation de ces annotations peut permettre d'exécuter du code entièrement non transactionnel dans un EJB. Cela peut mener à des améliorations de performances notables.