IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement Web avec .NET Discussion :

Web Service / SQL / Multithread / thread-safe


Sujet :

Développement Web avec .NET

  1. #1
    Membre régulier
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 69
    Points : 82
    Points
    82
    Par défaut Web Service / SQL / Multithread / thread-safe
    Bonjour,
    pour un logiciel de tarification qui fait appel a des web services, je voudrai modifier l'existant pour que cela aille plus vite.
    Il y a deux mode de tarification, SQL ou via web service
    J'ai vu qu'on pouvais faire du multithread avec WCF, j'ai essayé dans un petit projet de test et en effet en multithread ca fonctionne impec, et 3 appel a un web service qui met 3seconde a répondre met au total 3second.

    Par contre quand j'essai de faire la meme chose sur un gros project déjà fini,
    ca plante a moitié (j'ai pas tous le temps de meme résultat) et je comprend pas très bien la notion de thread safe, comment peut'on controller qu'un morceau de code est thread-safe ?
    Je pense que ca bug pas mal a cause des acces a SQL dans chaque thread, déjà je vais essayé de faire le SQL avant de commencé les thread et mettre les tarification SQL dans un thread unique et un autre thread pour les tarification Web Service.

    Si vous avez quelque conseill pour que j'arrive a m'en sortir, notament comment débugué chaque thread. Comment s'assuré que mon code est thread safe. Est ce que si le new d'un datacontext Linq est fait dans le thread la class datacontext est alors consiféré comme thread-safe ?

    Merci, ++

  2. #2
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2010
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Septembre 2010
    Messages : 7
    Points : 15
    Points
    15
    Par défaut
    En fait le multi-thread n'est pas spécifique à WCF. Pour controller si un morceau de code est thread safe il doit etre dans une portion protegée avec le mot clef lock ou bien dans une methode marquée avec l'attribut [System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.Synchronized)].


    Pour une meilleure comprehension (connaitre plus précisément le partage des ressources entre threads, leurs portées, et enfin faire attention aux Dead locks etc...):
    http://www.yoda.arachsys.com/csharp/threads/

  3. #3
    Membre confirmé Avatar de NicoL__
    Homme Profil pro
    Architecte
    Inscrit en
    Janvier 2011
    Messages
    399
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte

    Informations forums :
    Inscription : Janvier 2011
    Messages : 399
    Points : 577
    Points
    577
    Par défaut
    A priori un service web est multithreader, en gros chaque appel crée un thread. Qu'est ce qui a été multithreadé ? Le code client ou le code dans le service ?

  4. #4
    Membre régulier
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 69
    Points : 82
    Points
    82
    Par défaut
    C'est le code client qui a été multithread, le code client utilise egalement SQL, un coup SQL , un coup un webservice,

    en gros

    THREAD 1 => SQL
    THREAD 2 => WCF
    THREAD 3 => SQL
    THREAD 4 => WCF

    Je précise SQL car je me demande si deux thread peuvent utiliser SQL en même temps,
    En fait je croyais que le lock étais l'équivalent des mutex, et donc que ca "déthreadai" la partie de code qui etais dans le bloc lock,
    mais a priorie non...

  5. #5
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    Octobre 2009
    Messages
    153
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2009
    Messages : 153
    Points : 105
    Points
    105
    Par défaut
    qu'entends-tu par l
    C'est le code client qui a été multithread
    je pense bien que le fait que chaque requête soit traité par un thread est un comportement propre aux serveurs web et non au client qui s'y connecte.
    je me demande si deux thread peuvent utiliser SQL en même temps,
    les threads par définitions s'exécute dans un espace de ressource commune. aussi, ils ont tous accès à l'espace d'adressage alloué au processus qui les contients. ils manipulent de ce fait les mêmes objets y compris les ressources SQL. il revient au développeur de synchroniser l'accès à certaines ressources.

  6. #6
    Membre régulier
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 69
    Points : 82
    Points
    82
    Par défaut
    Je vais préciser l'architecture :

    SERVEUR WEB qui utilise un WEB services qui a une routine parrallel.Foreach
    => THREAD 1 (Se connect a un web Service A)
    => THREAD 2 (Se connect a une base C avec LindToSQL)
    => THREAD 3 (Se connect au web service A mais avec une nouvelle instance)
    => THREAD 4 (Se connect a la meme base C mais avec un nouveau context)
    => THREAD 5 (Se connect a un web service B)

    Ce que je ne comprend pas c'est qu'elle object je doit locker il y'en a qui son utiliser dans plusieur thread mais je ne sais pas vrement lequel, et je ne sais pas qu'elle object va utiliser un object d'un autre thread c'est pour ca que j'aiemrrai bien pouvoir débuguer ...
    Sinon je vais locker tous mes object,
    J'ai pas compris si locker et synchroniser voulais dire la meme chose , mais si je synchronise tous mes object alors le multithread ne sert plus a rien...

  7. #7
    Membre confirmé Avatar de NicoL__
    Homme Profil pro
    Architecte
    Inscrit en
    Janvier 2011
    Messages
    399
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte

    Informations forums :
    Inscription : Janvier 2011
    Messages : 399
    Points : 577
    Points
    577
    Par défaut
    Avec un parrallel.Foreach je ne vois pas comment lancer en parallel des méthodes différentes et connaitre combien de thread sont vraiment utilisées. A priori cela parallélise un N appels à une méthode et cela gère un pool. Il faut bien entendu que l'objet contenant la méthode soient threadsafe.

Discussions similaires

  1. Appeler un web service avec pl/sql
    Par squalito dans le forum PL/SQL
    Réponses: 5
    Dernier message: 17/09/2012, 15h21
  2. java.sql.Date et les web services
    Par technopole dans le forum Services Web
    Réponses: 5
    Dernier message: 03/04/2010, 12h59
  3. Web service natif SQL server avec parametre
    Par karngates dans le forum Services Web
    Réponses: 0
    Dernier message: 07/11/2008, 10h48
  4. Réponses: 4
    Dernier message: 06/03/2008, 13h08
  5. Réponses: 5
    Dernier message: 06/02/2008, 00h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo