Q: J'utilise sur Internet Information Server (IIS) 4.0 une application qui se sert de l'événement Session_onEnd pour déclencher le nettoyage concernant l'application. J'ai constaté que l'événement ne déclenche pas toujours quand une session se termine. D'après certains articles et newsgroups, ce serait un bogue bien connu. Je ne peux pas
IIS 4.0 et Session_onEnd

trouver
une telle référence, mais il est
clair que Session_onEnd ne fonctionne
pas comme prévu dans IIS
4.0. Mes tests avec Internet
Information Services (IIS) 5.0
montrent que Microsoft a apparemment
corrigé le problème.
Pouvez-vous m’éclairer sur ce
bogue en IIS 4.0 ?
R: Plus qu’un bogue, c’est un problème
de threading COM. Pour vous
répondre, il faut savoir comment les
composants COM fonctionnent avec
les divers modèles de threading. Cette
réponse ne permet pas de fournir des
détails sur ce sujet important, mais les
administrateurs d’IIS devraient s’intéresser
de près à ce sujet pour plusieurs
raisons. La principale préoccupation
est que les objets COM que votre système
utilise (y compris les objets COM
fournis par Microsoft) peuvent influencer
considérablement les performances
et l’évolutivité.
Quand vous créez un objet COM,
un modèle de threading lui est attribué.
Il en existe trois :
• Apartment threading – Un seul
thread provenant d’un objet peut
communiquer avec le serveur. Vous
pouvez cependant avoir plusieurs
instances de l’objet, chacune avec
son propre thread. Ce modèle de
threading est le seul que le moteur
de base de données Microsoft Access
supporte, ce qui est la principale raison
pour laquelle Microsoft recommande
Microsoft SQL Server comme
la base de données à utiliser avec IIS.
• Free threading – Un objet peut utiliser
(engendrer) plusieurs threads.
• Both threading – On peut accéder à
un objet comme un objet Apartment
threaded ou un objet Free-threaded.
Vous demandez pourquoi
Session_onEnd ne semble pas déclencher
dans IIS 4.0, mais semble fonctionner
dans IIS 5.0. Par défaut, ADO
est marqué comme Apartment threaded
dans le registre, ce qui signifie
qu’un seul thread est sollicité pour une
requête d’accès à la base de données.
Dans ce mode, le thread qui crée l’objet
ADO est le même thread qui doit
détruire l’objet ADO. Supposons qu’un
utilisateur adresse une requête à une
base de données qui n’est pas disponible
pendant 15 minutes. De guerre
lasse, l’utilisateur quitte la page et revient
au téléchargement des fichiers
.mp3 ou à toute autre occupation qu’il
avait entreprise. La session utilisateur
est terminée, mais le thread qui doit
détruire la session n’est pas disponible
parce qu’il est encore en train d’attendre
sur la base de données.
Session_onEnd déclenche bien, mais
un thread ne peut pas détruire l’objet
ADO parce que le seul qui en serait
capable est occupé. Ce délai donne
l’impression que Session_onEnd n’a
jamais déclenché.
Cette même suite d’événements
peut se produire si vous essayez d’utiliser
des objets Active Server Pages
(ASP) dans Session_onEnd. Vous ne pouvez pas, par exemple, utiliser
l’objet Response pour envoyer des informations
au navigateur parce que la
session est fermée. Ce fait semble
peut-être évident à certains, mais il
échappe pourtant à beaucoup de programmeurs.
Donc, comment Microsoft a-t-elle
amélioré cette fonctionnalité dans IIS
5.0 ? IIS 4.0 s’en remet aux paramètres
du registre qui dit qu’ADO est
Apartment threaded, mais IIS 5.0 ne le
fait pas. Au lieu de cela, IIS 5.0 interroge
le composant pour obtenir son
modèle de threading. ADO est en réalité
Both threaded, donc IIS 5.0 peut
créer l’objet ADO sur un thread, puis
utiliser un autre thread pour détruire
l’objet ADO. Cette possibilité donne
l’impression que l’événement
Session_onEnd semble corrigé dans
IIS 5.0.
Vous pouvez reconfigurer ADO
pour qu’il soit marqué comme Both threaded sur Windows NT 4.0 en modifiant
le registre. (Soyez toujours très
prudent quand vous modifiez le registre.)
Microsoft fournit un fichier
pour aider à cette reconfiguration.
Pour reconfigurer ADO, procédez
ainsi :
1. Trouvez le fichier adofre15.reg. (Si
vous avez accepté les valeurs par défaut
pour l’emplacement du fichier
de programmes quand vous avez
installé IIS, adofre15.reg sera dans
C:\program files\common files\systemado.)
2. Faites du répertoire contenant le fichier
votre répertoire courant, et
émettez la commande regedit
adofre15.reg. Réinitialisez le serveur.
3. Si vous procédez aux changements
ci-dessus et décidez de revenir
au modèle Apartment threaded,
répétez l’opération ci-dessus avec la
commande adoapt15.reg.
Téléchargez cette ressource

Rapport Forrester sur les solutions de sécurité des charges de travail cloud (CWS)
Dans cette évaluation, basée sur 21 critères, Forrester Consulting étudie, analyse et note les fournisseurs de solutions de sécurité des charges de travail cloud (CWS). Ce rapport détaille le positionnement de chacun de ces fournisseurs pour aider les professionnels de la sécurité et de la gestion des risques (S&R) à adopter les solutions adaptées à leurs besoins.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
