Session ASP.NET et stockage d'objets utilisant COM interop

Question

Je travaille sur un site Web asp.net. Nous devons utiliser com interop pour interagir avec les composants vx6 ActiveX hérités. Dans de nombreux cas, les composants reposent sur la réception d'un objet contexte (qui est lui-même un composant vx6 activex) en tant que paramètre. L'objet contexte est assez coûteux à construire.

Par conséquent, une idée est qu'un objet de contexte est construit une fois et stocké dans une session asp.net. Toutefois, si cet objet est juste un wrapper .net autour d'un composant activex, est-il sage ou conseillé de conserver un tel objet en session?

De plus, l'objet de contexte contient des informations spécifiques à l'utilisateur, donc la persistance de l'utilisation de .net HttpRuntime Caching pourrait être utilisée, mais nécessiterait une clé spécifique à l'utilisateur.

Je comprends les autres limitations et les choses dont vous devez être conscient avec la session asp.net, aspnet-session question.

Pour poser la question d'une manière légèrement différente: sont leurs problèmes ou problèmes avec le stockage d'un objet .net qui est juste un emballage autour d'un objet com?

Answer 1

Je pense que vous aurez très rapidement des problèmes avec une demande bloquant une autre. Par défaut, ASP.NET initialise COM sur ses threads pour placer le thread dans un appartement multithread. Les composants VB6 étaient au mieux des appartements-modèles. Cela signifie que lorsque le thread MTA crée le composant, il est placé dans le STA principal s'il existe déjà (ce qui n'est pas le cas pour les processus de travail ASP.NET) ou qu'un nouveau thread est créé spécifiquement pour le STA. Peu importe quel thread MTA crée le composant, le même STA est toujours utilisé pour les composants qui ne peuvent pas gérer le modèle MTA. Cela signifie que le même thread est utilisé pour chaque appel à ces composants, de sorte que les appels simultanés doivent attendre en ligne. Pour indiquer à ASP.NET d'initialiser COM pour les composants à un seul thread, ce qui entraînera la création de l'objet sur le même thread que la page en cours d'exécution, ajoutez l'attribut AspCompat à la directive @Page.

Je ne mettrais pas en cache les objets car ils sont susceptibles d'avoir des problèmes d'interconnexion lorsqu'ils sont réutilisés.

Answer 2

Je persisterais dans le cache, de cette façon il n'est pas construit une fois par utilisateur, sauf si c'est l'effet désiré.