Question par rapport à un accès concurrentiel

Salut à tous,

je viens ici poser une petite question qui me trotte par rapport à un accès concurrentiel aux données.

Je vous explique rapidement mon schéma :

j'utilise Spring pour un projet, spring-mvc, orm, et tout ce qui va avec. Dans ma conf, je définis un bean "DAO" qui est donc un singleton.

Code:

---

<bean id="daoImpl" class="projet.services.persistence.DaoImpl"/>

---

Dans cette même conf je définis un bean "sessionPref" de scope "session" qui me sert à mémoriser des données étant relatives à ma session.

Code:

---

1 2 3 4

<bean id="sessionPref" class="projet.helpers.session.SessionPrefs" scope="session"> <aop:scoped-proxy /> </bean>

---

Ma DAO se sert lorsqu'elle réalise des opérations avec l'ORM, de ce bean "session" pour pouvoir opérer correctement, il lui est injecté en utilisant directement dans la DAO un

Code:

---

1 2	@Autowired private SessionPrefs sessionPref;

---

Ma question est la suivante :

n'y a-t-il pas un risque que les objets "sessionPref" se "mélangent" dans ma DAO si par exemple deux exécutions se déroulent en même temps, quasiment au même moment, sachant que dans ma DAO je n'ai ajouté aucun synchronized sur ce "sessionPref"?

Je ne sais pas trop comment je pourrai tester ça mais j'ai lu des posts sur le net ou des personnes ont rencontré des problèmes de "données fantômes" dûes à ça, si d'ailleurs vous avez des conseils à ce sujet je suis preneur! :)

Merci!! :)

Bonjour,

LA session HTTP n'est pas Thread Safe. Cela signifie que dans le cas d'accès simultanées en écriture (si c'est bien votre cas), le développeur sera en charge de la synchronisation au risque de comportements non maîtrisés.

La question qui se pose alors est si on a bien des accès simultanés sur une même session HTTP (sachant qu'une session est associée à un utilisateur unique).

Merci de ta réponse vhalalla,

la session n'est pas ThreadSafe mais, dans un controlleur au sein d'un containeur Spring, annoté par le "@Controller", la manipulation des sessions est bien threadsafe non?

Car le seul endroit ou je manipule mon bean de scope "session" pour y écrire des valeurs, c'est dans les méthodes d'un controlleur. Je ne fais que lire des valeurs dans la DAO, et j'avoue que la problématique de la DAO en singleton m'a un peu interpellé concernant la concurrence, vu que je ne sais pas trop comment tester que tout se passe bien surtout...

Citation:

---

Envoyé par Yoann.chambonnet

Merci de ta réponse vhalalla,

la session n'est pas ThreadSafe mais, dans un controlleur au sein d'un containeur Spring, annoté par le "@Controller", la manipulation des sessions est bien threadsafe non?

---

Techniquement non, elle n'est pas threadsafe:) Après si vous êtes sur qu'un même utilisateur ne requête jamais votre contoller de façon concurrente y a pas de soucis.
Par contre j'imagine qu'avec une appli web qui utilise de l'AJAX pour récupérer des valeurs pendant que l'utilisateur fait lui même ses propres interactions sur la page on peut potentiellement commencer à avoir des résultats bizarres :). Même chose si l'appli utilise des Frames.
En fait, dés qu'il peut y avoir plusieurs requêtes simultanées vers le serveur pour le même utilisateur, il faut penser à synchroniser l'accès à sa session (ce que très peu de développeurs font)

Très bien, enregistré, merci beaucoup des conseils vhalalla!

Je vais regarder un peu mieux et me rédiger des tests pour mettre en évidence ça.

Je laisse le post ouvert pour un petit moment si quelqu'un a des précisions à apporter.

Pas de pb ;)

J'ai trouvé le lien suivant (en anglais) qui traite du pb. C'est intéressant!!

http://www.ibm.com/developerworks/li...-jtp09238.html

L'introduction dit: "The result is that many stateful Web applications have subtle and serious flaws" :)

Très intéressant cet article vhalalla, je pense du coup ne pas être concerné car je ne rentre pas dans la mise à jour mais juste la lecture des données, surtout que j'ai bien l'impression que le scope session des beans soit thread-safe : des tests que je viens de réaliser me laissent penser que tout ça fonctionne bien : pas de données "fantômes"!

J'ai croisé du coup d'autres questions, genre par ici mais pour la peine, tout roule pour moi :) merci beaucoup des infos.

:ccool: