Acces simultanés à security.xml

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

Citation:

---

Envoyé par Georges_Lauret

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

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.