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.