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)

[calagan99]

Philippe : merci pour ces informations.
En effet, dans la mesure du possible, je fais en sorte de ne pas stocker d'objet trop volumineux en session.

Cela dit, je me pose une question :
sur une appli à forte charge dont l'objet "principal" (entendre le plus manipulé : création, édition, recherche, visualisation, etc.) serait volumineux et pas "cachable" car subissant des modifications constantes : comment arbitrer entre un nombre de requêtes SQL Server important pour récupérer ces objets et un maintient de cet objet en session pendant toute sa phase d'utilisation par un user ?

[nah666]

Cela dit, je me pose une question :
sur une appli à forte charge dont l'objet "principal" (entendre le plus manipulé : création, édition, recherche, visualisation, etc.) serait volumineux et pas "cachable" car subissant des modifications constantes : comment arbitrer entre un nombre de requêtes SQL Server important pour récupérer ces objets et un maintient de cet objet en session pendant toute sa phase d'utilisation par un user ?

Si j'ai bien compris ta question je vais me permettre d'essayer de répondre:

Ton objet complexe énorme est forcément constitué d'objets de moindre taille, de liste d'objets etc...

Il faut donc mettre en place une gestion de cache fine pour les enfants et non pas l'objet global, tu peux après facilement reconstituer ton objet composé des enfants en cache.

Ce découpage te permet d'avoir une dépendance de cache, et de tout facilement faire tomber le cache sur les éléments modifiés ce qui réduit le nombre de requêtes SQL au minimum indispensable.

Evidemment cette gestion du cache est masquée par une couche d'abstraction, ce qui permet aux classes de haut niveau de manipuler les données sans se préoccuper de si on va les chercher dans le cache ou en BDD.

C'est la façon de faire que j'ai vu, et mis en place dans tous les gros projets web pour lesquels j'ai travaillé.

A mon sens ce n'est pas le rôle de la session, qui est dédiée à chaque utilisateur et dont le rôle est vraiment de stocker des informations temporaires liées à la connexion (langue choisie ou préférences par exemple), données très légères par définition.

[WebPac]

Bonjour,

je relance le sujet car j'ai avancé sur le dossier mais n'ai pas encore trouvé de solution.

Je mets en session un objet COM qui possède un certain nombre d'objets COM car leur chargement est long et leur chargement est fortement dépendant de l'utilisateur quand il se loggue.

Les objets COM, c'est moi le développeur et je ne peux pas m'en passer car tout le métier est dans cette bibliothèque qui n'a pas encore été redéveloppée en C#.

L'accès à cet objet passe par un wrapper et il est possible de ne plus utiliser la session mais le cache. En utilisant le cache, j'ai le même problème qu'avec la session.

En fait, il suffit de ne plus toucher au site pendant 5 minutes et dès qu'on fait une action, le pool d'application plante.

[WebPac]

Finalement, je n'ai pas trouvé de solution au problème, j'ai repris le code de la bibliothèque COM et l'ai porté en assembly .net que j'intègre dans le site asp.
Ca marche ainsi car il n'y a plus d'Interop.