Discussion :

[kileak]

Bonjour,

je souhaiterais lever un doute sur le comportement des méthodes statiques en .Net.
J'ai une classe statique Outil. Cette classe a des méthodes statiques qui ne font que de la manipulation de données. Pas de problème.

Là, je viens d'ajouter une autre méthode statique. Mais à la différence des autres, elle instancie d'autres objets pour fonctionner. Est-ce que je m'expose à un problème d'accès concurrent ? (je ne sais pas si l'on dit comme ça mais je pense que vous voyez de quoi je parle )

Le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public static string Print(MyXml dataImpr, string sDataModelFile, string sTemplateFile)
        {
            MyXml Impr = new MyXml("root");
            Impr.Append(dataImpr);
 
            Document myDoc = new Document(Impr,sDataModelFile,sTemplateFile);
            myDoc.Save();
 
            return myDoc.GuDocId;
        }

merci
Cordialement

[Nathanael Marchand]

Oui tu peux avoir des problèmes d'accès concurrent. Dans le code que tu manipules ca devrait aller mais d'une manière générale c'est possible.
Cependant, avoir des méthodes statiques pour accéder à la base de données c'est pas génial. Il vaut mieux préférer un singleton sur lequel il est possible de contrôler la durée de vie.

[tomlev]

Dans le code que tu montres je ne vois aucun problème potentiel : vu que les instances que tu crées sont locales à la méthode, elles ne seront pas manipulées par la même méthode dans un autre thread (vu que chaque thread a sa propre pile)

[kileak]

Merci à tous les deux.

En fait, tomlev me rassure mais je précise tout de même que je suis mono-threadé car appli web (le multi est interdit dans ma boite). Je ne pense pas que cela joue donc.

@Nathanael : j'entends bien le prob d'accès à la BDD. Mais ce n'est pas le cas là. Je construis un XML à la main.

Encore merci
bonne soirée

[Nathanael Marchand]

T'es sur de ton coup la?
Un serveur web mono-threadé, tu vas pas aller loin là

[tomlev]

En fait, tomlev me rassure mais je précise tout de même que je suis mono-threadé car appli web (le multi est interdit dans ma boite). Je ne pense pas que cela joue donc.

Euh... au contraire, une appli web est intrinsèquement multi-thread ! à moins que tu ne puisses traiter qu'une seule requête à la fois, mais alors la montée en charge risque de poser de sérieux problèmes

Si tu étais effectivement mono-threadé, la question de l'accès concurrent ne se poserait même pas...

[nevaram]

Je pense aussi qu'en appli web, c'est multi thread ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
Public class MyClass : System.Web.UI.Page
{
    static int _counter = 0;
    public static int Inc()
    {
         return _counter++;
    }
 
    public override void PageLoad()
    {
         label.Text = Inc();
    }
}

Si quelqu'un a un environnement sous la main pour tester ça

[tomlev]

Si quelqu'un a un environnement sous la main pour tester ça

Il n'y a rien à tester, c'est sûr à 100% que c'est multi-thread (du moins en ASP.NET). Mais de toutes façons ton test ne voudrait pas dire grand chose : comment tu saurais si 2 requêtes ont été exécutées en même temps ou successivement ?

[DonQuiche]

Il n'y a rien à tester, c'est sûr à 100% que c'est multi-thread (du moins en ASP.NET). Mais de toutes façons ton test ne voudrait pas dire grand chose : comment tu saurais si 2 requêtes ont été exécutées en même temps ou successivement ?

Effectivement, il n'y a pas de garantie qu'il y aura bien deux accès concurrents à la variable : si l'incrémentation ne représente que un millionième du temps passé à satisfaire la requête d'une page web, même un million d'accès concurrents laisseraient une bonne chance de ne voir aucun problème.

Par contre, je connais mal asp.net. Les traitements des requêtes sont bien sûr traités en parallèle mais encore ? Dans des threads différents (bassin de threads) ou bien également dans domaines d'application différents (avec un nouveau domaine à chaque requête) voire dans des processus différents (bassin de processus) ?

[tomlev]

Par contre, je connais mal asp.net. Les traitements des requêtes sont bien sûr traités en parallèle mais encore ? Dans des threads différents (bassin de threads) ou bien également dans domaines d'application différents (avec un nouveau domaine à chaque requête) voire dans des processus différents (bassin de processus) ?

Je suis pas non plus expert en ASP.NET, mais a priori avec IIS c'est quelque chose comme ça :

Même process
Même domaine d'application (pour une appli donnée du moins ; a priori 2 applis distinctes ne partagent pas le même domaine)
Un thread par requête (probablement des threads du pool, mais j'ai jamais vérifié)

[Bluedeep]

Par contre, je connais mal asp.net. Les traitements des requêtes sont bien sûr traités en parallèle mais encore ? Dans des threads différents (bassin de threads) ou bien également dans domaines d'application différents (avec un nouveau domaine à chaque requête) voire dans des processus différents (bassin de processus) ?

Avec IIS, tu as un domaine d'application par site : IIS est l'utilisateur "primitif" du concept de domain d'application de .NET. (question classique que je pose toujours en entretien ) Et un thread par requête (comme déjà dit par tomlev).

[DonQuiche]

Merci beaucoup à vous deux pour vos réponses.

[tomlev]

Avec IIS, tu as un domaine d'application par site

Ah bon ? Donc plusieurs applis ASP.NET qui tournent sur le même site se partagent le même AppDomain ? J'aurais cru qu'il y avait une isolation totale entre 2 applis...

[Bluedeep]

Ah bon ? Donc plusieurs applis ASP.NET qui tournent sur le même site se partagent le même AppDomain ? J'aurais cru qu'il y avait une isolation totale entre 2 applis...

Tu as raison, j'ai fait un racourci. J'aurai du écrire un domain par appli ou préciser ce que j'entend pas "site". Comme en générel on associe une adresse (un site) à une appli, j'ai fait un amalgame manquant de précision. (clair pour moi, mais pas clair dans son explication, quoi ....).