Discussion :

[jadey]

Hello les gens,
Je réalise une sorte de caddie virtuel en utilisant un EJB session avec état, jusqu'ici rien de bien extraordinaire.

Le problème de ma vie d'aujourd'hui est que mon EJB ne veut rien garder de ce que lui passe le client

J'ai donc une question:
Quand on travail avec des ejb session avec état, est ce qu'il faut garder une référence de l'instance du bean pour maintenir l'état conversationnel ?

A chaque fois que je fais un lookup pour récupérer mon interface locale le conteneur m'en sert une nouvelle j'ai l'impression, car les attributs du bean session sont vides.
Il faut peut être spécifier quelque chose de particulier sur le descripteur de déploiement EJB pour celui ci ?

Voici le code de mon session bean, attention au yeux c'est un 2.1:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
package com.laoujebosse.leprojet.ejb.session;
 
import java.util.ArrayList;
 
import com.laoujebosse.leprojet.beans.GenericBean;
 
/**
 * Bean implementation class for Enterprise Bean: CaddieACommissions
 */
public class CaddieACommissionsBean implements javax.ejb.SessionBean {
 
	static final long serialVersionUID = 3206093459760846163L;
	private javax.ejb.SessionContext mySessionCtx;
 
	/**
         * getSessionContext
         */
	public javax.ejb.SessionContext getSessionContext() {
		return mySessionCtx;
	}
 
	/**
         * setSessionContext
         */
	public void setSessionContext(javax.ejb.SessionContext ctx) {
		mySessionCtx = ctx;
	}
 
	/**
         * ejbCreate
         */
	public void ejbCreate() throws javax.ejb.CreateException {
	}
 
	/**
         * ejbActivate
         */
	public void ejbActivate() {
	}
 
	/**
         * ejbPassivate
         */
	public void ejbPassivate() {
	}
 
	/**
         * ejbRemove
         */
	public void ejbRemove() {
		content = new ArrayList<GenericBean>();
	}
 
	ArrayList<GenericBean> content = new ArrayList<GenericBean>();
 
	public ArrayList<GenericBean> addContent(GenericBean newContent) {
		content.add(newContent);
		return content;
	}
 
	public ArrayList<GenericBean> getContent() {
		return content;
	}
 
	public GenericBean getContentDetails() {
		Integer nbrFiles = content.size();
		Integer nbrRows = 0;
		for (GenericBean bean1 : content) {
			ArrayList<GenericBean> bean2 = (ArrayList<GenericBean>) bean1
					.getValue();
			nbrRows += bean2.size();
		}
		GenericBean result = new GenericBean(nbrFiles, nbrRows);
		return result;
	}
}

Merci d'avance pour toutes vos contributions.

[hhfr]

Oui en effet, un statefull ne veut pas dire qu'il soit associé à la session utilisateur, c'est plus large que cela.

En fait statefull définit entre autre chose, que lorsque le conteneur le "passivate", celui ci sauvegarde l’état de celui ci. Lors de l'activation, il restaure cet état. A contrario d'un stateless est simplement détruit si le besoin s'en ressent.
Il faut comprendre que le cycle de vie des EJBs est géré par le conteneur.

Pour associer un statefull de type caddie à un user, tu dois l'associer à sa session. Enfin lorsque tu en as de nouveau besoin, tu dois aussi allé le chercher dans la session.

[jadey]

Oui en effet, un stateful ne veut pas dire qu'il soit associé à la session utilisateur,

C'est franchement étonnant.

Pourquoi alors ne pas mettre mes attributs dans un bean (instance d'un objet normal) et mettre celui-ci en session. C'est vrai qu'après tout les services fournis par le conteneur en ce qui concerne les EJB session sont quasi-invisibles pour le développeur (pas de persistance ni d'appel explicite au méthode de sérialisation dé-sérialisation)
Je suis déçu mais je suis sûr qu'il y a quelque chose qui m’échappe.

[Desboys]

Comme indiqué par HHFR, il faut garder une "handle" vers ton EJB, car son cycle de vie est différent.

Pense au scénario suivant:
Ton application JEE est déployée sur un cluster de serveur d'application ( 3 noeuds ), avec réplication des sessions web entre les noeuds ( passons outre la réplication des SFSB ).
Sur ton noeud 1, ton utilisateur effectue ses transactions web, tu as récupéré un accès à un EJB stateful ( supposons qu'il soit hébergé sur le noeud 2 ). Ton noeud 1 plante pour une raison X ou Y, ton cluster se retrouve amputé d'un participant, mais reste fonctionnel. Ton utilisateur poursuit l'utilisation de son caddie, et est redirigé sur le noeud 3 puisque le noeud 1 est perdu. Si tu as gardé ta "handle" vers l'EJB stateful en session web, ton utilisateur ne détectera pas ce problème. Il continuera à agir sur son caddie, sans souffrir de cette avarie du cluster.
Si l'association avait été gardée dans la JVM du noeud 1, alors tu aurais perdu ton caddie, et la panne aurait été visible de l'utilisateur, ce qui n'est pas forcément souhaitable.

Désolé pour le pavé :-)

Sébastien

[jadey]

il faut garder une "handle" vers ton EJB

Moi ou le serveur d'application ?
Bon, question:
Si je veux associer mon EJB à la session de l'utilisateur il suffit de mettre l'EJB dans la session, c'est le meilleur moyen ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

request.getSession().setAttribute("caddie", local);

[jadey]

ou je défini l'EJB parmi les attribut du form si je travaille en struts? Mais ça va m'obliger d'une part à associer le form au scope session, et à devoir utiliser la même classe de formulaire pour toutes les actions qui utilisent le panier.

[jadey]

Personne n'a de solution ou de réponses pour résoudre mon problème

[electro-rifino]

ALor est ce ke ta trouvé une réponse a ta kestion ? si oui explique nous parcque j'ai le meme prob

[jadey]

Bah non en fait. J'ai eu l'occasion de passer à autre chose mais j'aimerais bien avoir une réponse moi aussi

[OButterlin]

la session http semble être le meilleur emplacement pour stocker la référence de ton EJB stateful.
Ceci dit, dans le cas d'une application web simple, on peut se poser des questions sur l'intérêt d'un stateful, mais il en existe, ne serait-ce que d'un point de vue performance, ou quand on a un contexte particulier à traiter (toujours pénible de devoir passer en paramètre).