Le cycle de vie d'une instance d'EJB avec état est un peu plus complexe, du fait qu'une telle instance est attachée à un client donné. Dès qu'un EJB avec état répond aux requêtes d'un client, il devient dépendant de ce client et ne peut plus servir d'autres clients. Le serveur d'applications peut mettre en œuvre deux stratégies en cas d'inactivité d'un client.

Le cycle de vie d'un EJB avec état comporte quatre états.

Comme pour les EJB sans état, un EJB qui passe de l'état does not exist à l'état method ready se voit injecté toutes les valeurs qui doivent l'être. Lors de cette transition, la méthode annotée @PostConstruct est invoquée, si elle existe. Le passage de l'état method ready à does not exist s'accompagne également de l'appel à la méthode annotée @PreDestroy, si elle existe. La passivation et le réveil d'un EJB (transitions entre les états method ready et passivate ) s'accompagne également de l'appel de deux méthodes, annotées @PrePassivate et @PostActivate respectivement, si elles existent. Un EJB dans l'état passivate peut passer dans l'état does not exist, mais dans ce cas aucune méthode n'est appelée. Ce qui est assez logique, puisque que dans l'état passivate notre pauvre EJB n'est probablement qu'un amas informe d'octets rangés dans un tableau. Rappelons que l'état method ready in TX n'est utilisé que si la méthode métier est déclarée transactionnelle. Si tel est le cas, le passage de l'état method ready à method ready in TX peut s'accompagner de l'appel à plusieurs callbacks . Ces callbacks sont appelés si l'EJB session implémente l'interface SessionSynchronization, qui définit les trois méthodes suivantes : La méthode afterBegin() est appelée par le serveur d'applications au moment du démarrage de la transaction. Cette méthode est appelée une fois que la transaction a démarré (l'appel à sa méthode begin() a rendu la main). Il est donc possible de faire des opérations en base, qui seront menées à bien dans la transaction de la méthode métier. Lorsque cette méthode rend la main, alors l'EJB passe dans l'état method ready in TX . Lorsque la méthode métier termine son exécution, le gestionnaire de transactions fait un appel à la méthode commit() de la transaction dans laquelle cette méthode s'est exécutée. L'appel de cette méthode peut se terminer de deux façons : un succès ou un échec. En cas de succès, le retour de la méthode métier est envoyé au client, il s'agit du cas nominal. En cas d'échec, une exception est envoyée au client. La méthode beforeCompletion() est appelée par le serveur d'applications avant l'appel à la méthode commit() de la transaction. La méthode afterCompletion(boolean) est appelée par le serveur d'application une fois la transaction validée. Si cette validation est un succès, cette méthode est appelée avec le paramètre true, et false dans le cas contraire. L'EJB est donc informé du succès ou non de la transaction, et peut mettre à jour son état dans ces deux cas.