Discussion :

[KooKoolen]

Bonjour,

Ma question est d'ordre purement méthodologique. Lorsqu'on veut ajouter dans un EJB Session une méthode qui ne s'applique pas à une instance particulière de cet EJB, est-ce qu'il faut la déclarer static ou non ?

Techniquemment parlant, comment le conteneur gère l'appel de cette méthode ?

Merci !

[pedouille]

J'aurais tendance à dire que si tu as besoin de méthodes statiques, utilises un session stateless : ses méthodes sont par définition statique.

Si tu as tout de même besoin d'un statefull, le plus simple serait peut-être de mettre ta méthode statique dans un stateless (qui est plus économe que le statefull), et faire des appels sur le localHome...

J'espère que ça répond à ta question.

[manblaizo]

J'aurais tendance à dire que si tu as besoin de méthodes statiques, utilises un session stateless : ses méthodes sont par définition statique.

Si tu as tout de même besoin d'un statefull, le plus simple serait peut-être de mettre ta méthode statique dans un stateless (qui est plus économe que le statefull), et faire des appels sur le localHome...

J'espère que ça répond à ta question.

Ouh laaaa !!! Complètement hors de propos !! La notion d'EJB session stateless ou stateful n'a rien à voir avec le concept de classe statique. Il n'est pas dit que pour un session stateless les "méthodes sont par définition" statiques. Mais qu'une instance d'EJB stateless ne concerve pas d'information de session avec un utilisateur particulier et est par conséquent réutilisé plusieurs fois par le conteneur pour servir différents clients, d'où son côté "scalable"; contrairement à une instance d'ejb stateful qui est relié à un seul client durant la session utilisateur... Encore que même dans ce cas, le conteneur peut "passiver" l'instance ...
Par contre, concernant les méthodes statiques pour un EJB, je dirais qu'en principe rien n'interdit d'en définir pour la classe d'implementation de l'EJB et les utiliser de manière tout à fait classique en Java (MaClasseBean.methodeStatic() ). Mais c'est une pratique qui est "rarement" conseillée et sujet à de nombreuses discussions de style de programmation, etc.
Voici un lien, en anglais, où le débat était tout aussi animé :
http://www.theserverside.com/discuss...hread_id=22969

[pedouille]

En effet, je me suis mal exprimé. Par définition, un session stateless est un bean dont on ne retient pas l'état pour un utilisateur donné. De ce fait, toutes les méthodes d'un session stateless pourraient être déclarées statiques ; d'autant que le conteneur s'en sert comme il se servirait d'une classe statique - une instance pour tout le monde.

Ou alors j'ai vraiment rien compris ...

[manblaizo]

En effet, je me suis mal exprimé. Par définition, un session stateless est un bean dont on ne retient pas l'état pour un utilisateur donné. De ce fait, toutes les méthodes d'un session stateless pourraient être déclarées statiques ; d'autant que le conteneur s'en sert comme il se servirait d'une classe statique - une instance pour tout le monde.

Ou alors j'ai vraiment rien compris ...

Heu ! c'est pas tout à fait ça, en fait... Un session stateless ne conserve pas d'état de conversation avec un utiliseur particulier (il ne se souvient pas d'un utilisateur après l'avoir servi), et donc pour des raisons de performance, le conteneur peut créer à l'avance un certain nombre d'instances de ce bean et les placer dans un pool d'instances. Dans ce pool, toutes les instances sont identiques et interchangeables. Quand un appel émane d'un client donné, le conteneur choisit n'importe quelle instance du pool, gère la requête, puis renvoie l'instance dans le pool à la fin de l'exécution de la méthode pour pouvoir servir d'autres clients. Et donc, un même client peut être servi plusieurs fois par la même instance de bean, ou carrément par différentes instances du bean. Voilà, un petit peu le principe, mais les méthodes de la classe bean sont bien des méthodes d'instance et non des méthodes statiques.
J'espère avoir clarifié un peu le débat.