Rappelons ici qu'une transaction est une unité de travail, en général liée à des changements de données dans une base. Cette unité est vue comme une et indivisible, soit elle est menée à bien avec succès dans son intégralité, soit elle est entièrement annulée. Le support des transactions est un des points fondamentaux des EJBs. Pour le moment, nous nous sommes placés dans le cas où une méthode métier est exécutée dans le contexte d'une transaction. Dans ce cas, cette transaction est entièrement gérée par le serveur d'applications, sans que le développeur d'EJB n'ait à s'en soucier. Les choses sont en fait plus complexes : il existe deux contextes applicatifs. Dans le premier, appelé bean managed transaction , les transactions sont gérées manuellement, dans les méthodes métier des EJB. Dans le second, appelé container managed transaction , c'est toujours le serveur d'application qui gère la transaction, mais l'application a tout de même la main sur quelques aspects de sa gestion. Dans tous les cas, une transaction est toujours associée à une unité d'exécution ( thread ) particulière dans le modèle EJB.

Un EJB qui choisit de gérer lui-même ses transactions doit être annoté par @TransactionManagement, comme dans l'exemple suivant. Cette annotation ne peut être posée que sur une classe, le comportement d'un EJB vis-à-vis de la gestion des transactions est donc global à un EJB, et ne peut se régler méthode par méthode.

Dans le contexte application managed transactions les transactions sont gérées manuellement, comme si l'on était dans une application JSE. La seule différence est que, pour obtenir une transaction, l'on s'adresse tout de même au serveur d'applications. Une transaction est dans ce cas modélisée par l'interface UserTransaction. On peut récupérer cette transaction de deux manières : soit par injection de dépendances, soit en demandant cette transaction à l'annuaire du serveur. L'injection de dépendance est la manière la plus simple, que l'on montre sur l'exemple suivant. Enfin, rappelons que l'injection d'une transaction ne peut se faire que dans un EJB qui gère lui-même ses transactions, donc annoté avec @TransactionManagement(TransactionManagementType.BEAN). Dans le cas où les transactions sont gérées par le conteneur d'EJB, cette injection est illégale, et peut mener à une erreur de démarrage de l'application.
L'interface UserTransaction propose les six méthodes suivantes.

Dans un scénario JDBC classique, les choses se déroulent de la façon suivante : Un EJB n'ouvre pas une connexion sur une base de données de cette manière. Il le fait par injection de dépendances : Un EJB peut bien sûr utiliser autant de connexions sur autant de bases de données qu'il veut, soit directement soit au travers de JPA. Ensuite, il obtient une référence sur une transaction également par injection de dépendances, comme nous l'avons vu. Résumons tout ceci sur l'exemple suivant.
Cet objet de types DataSource permet de récupérer une connexion JDBC à une base de données en appelant sa méthode getConnection(). Se pose alors la question du lien entre la transaction obtenue, et les différentes opérations menées à bien au travers des différentes connexions JDBC, utilisées directement ou non. La réponse est fournie par la spécification EJB. Toute opération sur une base de données effectuée dans une méthode métier d'un EJB, après un appel à transaction.begin() est faite dans le contexte de cette transaction. Tous les principes de fonctionnement des transactions s'appliquent, en particulier l'atomicité et la cohérence. Le cas où l'on s'adresse à plusieurs bases de données différentes est ici nouveau, et pose le problème de la synchronisation des opérations. Cette synchronisation est résolue en procédant en deux temps, on appelle cette procédure le two phases commit .

Dans ce cas, une transaction peut être ouverte lors d'un premier appel de méthode métier, puis maintenue ouverte à la fin de cet appel. Un deuxième appel d'une autre méthode peut alors avoir lieu, dans la même transaction, toujours ouverte. Enfin un troisième appel peut valider (ou non) la transaction. Cette validation, ou cette invalidation, portera alors sur les opérations menées lors des trois appels successifs de méthode. Dans ce contexte, l'appel à la méthode getStatus() de l'interface UserTransaction renseigne sur l'état courant de cette transaction.