Discussion :

[WebPac]

Bonjour,

j'essaie de faire un site Web en ASP.NET qui utilise des objets non managés COM.
Je mets un objet COM en session puis le réutilise plus tard dans le site et parfois j'ai un message d'erreur (mais ce n'est pas systématique) :

l'accès à cet emplacement de la mémoire n'est pas valide Exception de HRESULT

J'ai tracé s'il est null et ce n'est pas le cas. J'ai aussi tracé s'il est détruit et son destructeur n'est pas non plus appelé.
Si je fais une garbage collection, cela ne bugue pas lors de la collection mais le bug continue à se reproduire aléatoirement.

Je pense que quelquechose m'échappe dans l'utilisation des objets non managés utilisés avec la session mais je ne vois pas quoi.

Merci pour votre aide.

[Immobilis]

Salut,

En web il est préférable de se passer des variables de session. C'est pratique, mais limité en espace, peut être effacé de la mémoire après un certain temps ou un redémarrage du processus de IIS, etc.

En as-tu vraiment besoin ou c'est juste du confort?

A+

[WebPac]

J'ai du mal à imaginer de mettre cette variable ailleurs que dans la session en fait car elle dépend du user logué.
De plus, il n'y a pas de problème lors du timeout de la session car le relogin automatique recharge la variable et la remet en session.

En fait, après différents tests, je pense que c'est à cause d'une requête asynchrone (en ajax donc) qui est trop longue à être traitée et du coup le navigateur abonne après un timeout.

Et quand l'utilisateur fait une seconde requête, on dirait que la variable automation en session est toujours en cours d'utilisation dans l'ancien thread, ce qui engendre cette erreur.

[Immobilis]

Ce serait intéressant que tu nous donnes un peu plus de détails sur la façon dont tu t'y prends. Quel est cet objet COM? Les objets non managés sont un peu délicats à utiliser. C'est un peu comme si tu voulais mettre un fichier texte ou une connexion SQL en session.

[calagan99]

En web il est préférable de se passer des variables de session

Immobilis, si tu ne les utilises pas en web, tu les utilises où ?
Je suis d'accord sur le fait qu'il ne faut pas en abuser, mais les variables de session sont quand même très utiles...

[Immobilis]

Immobilis, si tu ne les utilises pas en web, tu les utilises où ?

Autant que possible, nulle part Comme je dis, c'est préférable Selon les cas il y a souvent des alternatives. Dans le cas de WebPac j'ai pas assez de détails.

Pourquoi j'aime pas les variables de session? Parce que on ne sait jamais ce qu'on a mis dedans. C'est pas explicite, l'état des variables est incertain, c'est fourre-tout.

A+

[calagan99]

Et donc, tu assures comment la persistance des données dans une appli Web ?
Le cache, le viewstate ?

Je sais que, dans la mesure du possible, il faut faire en sorte de ne pas en abuser. Mais je ne comprends définitivement pas cette tendance au "Session is evil".
As-tu des exemples ou informations sur les raisons pour lesquelles il faut éviter de les utiliser ?

Attention, je pose la question, je ne dis pas que stocker un objet COM en session est une idée judicieuse

[Philippe Vialatte]

Mais je ne comprends définitivement pas cette tendance au "Session is evil".
As-tu des exemples ou informations sur les raisons pour lesquelles il faut éviter de les utiliser ?

Je ne sais pas quelles raisons poussent Immo a ne pas utiliser la session, mais:
- si elle est in process, elle peut être détruite a tout moment
- si on stockes de gros objets dedans, ils ont tendance a monter dans les niveau du GC, a ne plus être collectés->fuite mémoire et crash serveur
- si elle n'est pas in process, trop de développeurs oublient de supprimer de la session les variables dont ils n'ont plus besoin -> OutOfMemory

Perso, j'utilise des sessions, mais dans des cas limités:
- stockage de types "simples" (sauf cas exceptionnel, a documenter)
- écriture de wrapper autour des accesseurs (comme cas, pas de problème de faute de frappe, et si c'est bien fait, pas de problème de conversion)
- quand c'est une variable qui doit effectivement aller en session (durée de vie longue, commune a toutes les pages de l'application)