Discussion :

[h.daly]

Bonjour a vous,

je commence a m'interesser au developpement des EJB, vous avez sans doute vu que @Stateless est sans état : il ne conserve pas une mémoire
de ce quil a fait précédemment.
@stateful est le contraire.

pouvez vous me clarifier d'avantage ce concept avec un exemple concret, ou je me vois contraint d'utiliser une annotation et pas l'autre.

merci d'avance

[BugFactory]

Exemple de session bean statefull : le panier d'un site de vente par correspondance. Si l'utilisateur ajoute de nouveaux produits au panier, mieux vaut ne pas oublier tous les produits qu'il y a mis précédemment.

Exemple de session bean stateless : le catalogue. Un utilisateur peut consulter les fiches produits de plusieurs articles, on a pas besoin quel sont les articles qu'il a vu auparavant pour afficher la fiche du produit en cours.

[kalysto]

Une autre maniere de voir les choses :

Quand un client discute avec un EJB stateful, il dialogue toujours avec la même instance.
Tandis que si c'est un EJB stateless, il n'y aucune garanties que 2 appels consécutifs de méthodes soient traités par la même instance d'EJB.

[longbeach]

Autre exemple de stateless session bean : authentification.

[hhfr]

Ce qu'il faut comprendre avec les EJBs, c'est que c'est le conteneur qui gère le cycle de vie de ces objets. Ce qui implique qu'a aucun moment dans ton code tu ne verras un EJB instancié par tes soins.

Ceci implique plusieurs choses : c'est le conteneur qui décide à quel moment les instances des objet ont besoin d'être en mémoire.
Ainsi pour un stateless, au moment ou l'ejb est déchargé de la mémoire toutes les variables éventuellement utilisées par les méthodes ne seront pas préservées.
Lorsque un client demande à accéder à un EJB, si celui ci est en mémoire et non utilisé, il est directement donné à celui ci dans l'etat ou il se trouve.
Cela se traduit par 2 effets :
- 2 clients accédant à un même EJB, pourrait potentiellement voir les même valeurs, si le conteneur n'a pas déchargé l'EJB avant que le deuxième client y demande accés.
-1 clients accédant à un EJB à deux intervalles de temps, risque de ne pas voir les données initialisé dans les variables.

Pour un statefull, en revanche lors du déchargement de l'EJB de la mémoire une phase de "passivation" est initié, pour sauvegarder l'état de l'EJB.
L'utilisation des statefull ne dois pas être utilisé à la légère cela va de soit.
Pour autant si on veut qu'un client accède toujours à son statefull, il faut associer celui ci à sa session. sinon, à chaque fois que le client demande à accéder au satefull le conteneur le retournera un nouvel EJB.

Dans une architecture SOA, la notion de session devrait pas intervenir, le mieux est d'utiliser que des stateless. C'est mon avis.

Cordialement

[OButterlin]

Les EJB stateful ont un intérêt quand on veut faire des traitements sur plusieurs cycles. On peut paramétrer de manière fine les transactions, le moment où elles seront validées (commit) ou invalidées (+ sous-transaction).

Les stateless sont quant à eux un simple aller/retour entre le client et le conteneur, avec un paramétrage classique JTA, la transaction est validée à la sortie de la méthode ayant créé la transaction.

Dans un contexte web, rien n'empêche d'utiliser la session (http) pour stocker les données collectées sur plusieurs cycles et d'utiliser un stateless pour valider un graphe entier.
Tout peut se discuter