Discussion :

[Georges_Lauret]

Bonjour,

Je rencontre des problèmes lors de l'utilisation de XMLC_Security='GLOBAL" lorsqu'il y a beaucoup d'utilisateurs.

Mon serveur 2003+IIS possède 4 processeurs.

Dans les traces je vois apparaitre que security.xml était inaccessible parcequ'utilisé par un autre processus. Et à partir de là seul IISReset peut débloquer la situation car plus aucun nom d'utilsateur n'est reconnu.

Y a t il une configuration particulère à mettre en oeuvre pour gérer çà ?

La case à cocher "Dispatch requests using an independent thread (must be checked when using scripting)" (configuration des pools) est elle importante ? dans quel cas ? en particulier : faut-il la cocher si on a des gestionnaires d'évènement en JScript ?

Les threads à déclarer ds un serveur 4 processeurs ?

Merci de votre aide...
Georges

[Sylvain James]

Dans les traces je vois apparaitre que security.xml était inaccessible parcequ'utilisé par un autre processus. Et à partir de là seul IISReset peut débloquer la situation car plus aucun nom d'utilsateur n'est reconnu.

J'ai également constaté le même souci lors de montée en charge et une méthode peu avouable pour annuler le problème consistait à ouvrir security.xml dans notepad, faire une modif bidon (ajouter un espace) et enregistrer.
C'est moins brutal qu'un IIS Reset :-)
A mon avis c'est l'OS qui se mélange les pincettes sur les accès concurrents en rafale sur le même fichier.
Dans les cas de moyenne / forte charge, j'ai décidé de déporter la gestion de la sécurité en base de donnée (cf http://xmlrad.developpez.com/Articles/Authentification/.

Bon courage,
Sylvain

[RDM]

le problème c'est que le Security.xml n'est pas protégére de l'accès concurrentiel lors du login qui le met à jour.
Je suivrais l'avis de Sylvain pour la forte charge et d'autant plus lorsqu'on est en multi-processeur de passer les utilisateurs dans la base de données.