Discussion :

[didi]

Bonjour tout le monde !

j'ai une application web java EE (glassfish + jpa + jsf + primeface).
j'ai un soucis par rapport à la manipulation de mes données;

j'explique :

quand 2 clients se connectent (user A et user B) et ouvrent une même liste 'fournisseurs' (dataTable)

quand A sélectionne d'abord une ligne et l'édite et ensuite B fait pareil avec une autre ligne donc 2 fournisseurs distincts

si A fait des modifications et valide cela modifie l'enregistrement ouvert par B et vice versa.

En résumé toute modification effectuée par l'un des n users connectés à l'appli, se porte sur la dernière ligne sélectionnée par l'un des users
et non sur la ligne ouverte par le user .

je croyais que les annotations @sessionScoped et/ou @statless permettait de gérer efficacement les beans par rapport au context de
chaque utilisateur connecté

[OButterlin]

Ben là, sans voir ce que tu as codé, difficile de te dire ce qui ne va pas...

Comment fais-tu ton test ? Tu utilises 2 navigateurs différents ou tu le fais sur 2 onglets séparé ?
Il faut savoir que le numéro de session sera le même dans le cas où tu ouvres 2 onglets dans le même navigateur.

Pour répondre à ta question, oui, @SessionScoped est lié à la session (HttpSession) de l'utilisateur. Il ne devrait pas y avoir de conflit entre 2 utilisateurs.
Pour ce qui est de l'annotation @Stateless, là, on est dans un autre monde, celui des EJB.
Il n'y a pas de notion de session et donc, tout va dépendre de la façon de coder l'EJB, il ne doit pas y avoir d'éléments stockés en dehors de la méthode.

[didi]

Merci pour ta réponse OButterlin !

En fait pour mon test j'ai utilisé 2 navigateurs différents et mieux 2 machines clientes différentes

je vais creusé d'avantage pour trouver une solution

[tchize_]

Ca veux dire que tu as stocké l'information "ligne en cours de modification" ailleurs que dans la session. Pour faire simple, ton bean Stateless ne peux pas avoir de champ, tout doit se faire dans la méthode. Si tu veux stocker des trucs dans la session, il faut un StateFull. Ceci dit, il serait peut être préféréable de gérer ça en request scope plutot que dans la session.