Discussion :

[zax-tfh]

Bonjour à tous,

J'étudie actuellement l'intégration de NHibernate dans ASP.Net et je patauge sur un point :
Ils indiquent qu'il faut binder la session nhibernate au httpcontext lors du requestStart et fermer tout ca à la fin de la requete.

Je ne comprend pas pourquoi faire ceci ? et ne trouve pas d'info concrete (du moins pour moi) pour expliquer cette pratique.

Auriez vous par hasard une explication, des infos sur le sujet svp ?
Merci d'avance
@+

[Immobilis]

Salut,

Rien de certain dans ce que je dis, mais il me semble que NHibernate permet de gérer la persistance des données, c'est à dire de réaliser une mise en cache des données. Pour pouvoir reservir les données en fonction de l'internaute (pour ne pas reservir les mêmes données à tout le monde), il faut un moyen de reconnaître l'internaute. Rien de mieux que les identifiants de session.

A+

[zax-tfh]

Oui en fait, d'après ce que j'ai cru comprendre, il y a également une problématique au niveau du cycle de vie d'une page.
En fait, je suis en train de me poser une question concernant les données coté code behind.

Imaginons une classe mettant à disposition un object via une propriété statique . Imaginons que dans un bout de code behind je fasse appel à cette propriété, puis dans un autre bout j'y fais également appel, puis admettons dans un des évenements du global.asax aussi.
Logiquement je devrais avoir toujours le meme objet non ?
Maintenant, imaginons la meme scene se produisant en meme temps mais via un autre utilsateur. Logiquement il ne devrait pas avoir accès au meme objet que le premier user, je me trompe ?

Si j'ai raison, c'est pour ça que je suis un peu dans le flou, car pourquoi aller stocker cela dans le httpcontext alors qu'en variable ca fonctionne aussi bien ?

Alors après j'ai lu diverses choses concernant les threads, comme quoi une requete pouvait démarrer sur un thread A et terminer sur un thread B. Mais dans ce cas (je n'ai jamais fait l'essai et n'ai jamais eu besoin d'ailleurs) l'accès à la propriété via le thread A ne renverrai pas le meme objet que si on y accede via le thread B ?

[Immobilis]

Si j'ai raison, c'est pour ça que je suis un peu dans le flou, car pourquoi aller stocker cela dans le httpcontext alors qu'en variable ca fonctionne aussi bien ?

Les outils comme nhibernate permettent la persistance des données au de-là de deux requetes. Cela n'est pas possible avec une variable qui est détruite dès que la page est envoyée au client.

A+

[bacelar]

Une variable statique n'est unique que dans un AppDomain.
Si vous utilisez plusieurs AppDomain, vous aurez plusieurs variables statiques.

Les variables statiques ne sont ni liées à une requête, ni à un utilisateur du thread courant.

Il faut donc l'httpContext pour connaître une valeur fonction de l'utilisateur initiateur de la requête.

Si le thread B doit continué la tâche du thread A, il faut que le contexte du thread B est un moyen de retrouver l'httpContext initial, soit par la sérialisation automatique du contexte par ASP.NET (je suis pas très sûre que cela soit le cas actuellement), soit en le sérialisant dans les paramètres de la fonction exécutée par le thread B.