Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1430 connectés 

  FORUM HardWare.fr
  Programmation
  Java

  [java-servlet] question sur la conccurence

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[java-servlet] question sur la conccurence

n°186755
R3g
fonctionnaire certifié ITIL
Posté le 31-07-2002 à 09:25:06  profilanswer
 

Prise de conscience de bon matin : si j'ai bien compris, toutes les requetes destinées à ma servlet sont traitées par la meme instance de celle-ci.
Si ceci est vrai, y'a-t-il un controle de l'accès à cette servlet au niveau du container ?
Pour m'expliquer, voila ce qui m'angoisse : j'ai une servlet, avec des attributs (des variables d'instance quoi), et certaines methodes dans cette servlet modifient ces attributs. Hors j viens de réaliser que c'est une très mauvaise idée, car ces attributs pourraient se trouver modifiés par le traitement d'une requête pendant le traitement d'une autre.
D'où ma question : rassurez-moi, y'a-t-il un synchronized quelque part, ou est-ce que c'est à moi de le mettre ?

mood
Publicité
Posté le 31-07-2002 à 09:25:06  profilanswer
 

n°186758
El_gringo
Posté le 31-07-2002 à 09:26:52  profilanswer
 

J'crois que t'as une instance de servlet par requete client !

n°186760
El_gringo
Posté le 31-07-2002 à 09:27:41  profilanswer
 

a mon avis tu t'inquiètes pour rien.

n°186762
darklord
You're welcome
Posté le 31-07-2002 à 09:29:34  profilanswer
 

el_gringo a écrit a écrit :

J'crois que t'as une instance de servlet par requete client !




 
 [:tapai]


---------------
Just because you feel good does not make you right
n°186764
darklord
You're welcome
Posté le 31-07-2002 à 09:31:17  profilanswer
 

R3g a écrit a écrit :

Prise de conscience de bon matin : si j'ai bien compris, toutes les requetes destinées à ma servlet sont traitées par la meme instance de celle-ci.
Si ceci est vrai, y'a-t-il un controle de l'accès à cette servlet au niveau du container ?
Pour m'expliquer, voila ce qui m'angoisse : j'ai une servlet, avec des attributs (des variables d'instance quoi), et certaines methodes dans cette servlet modifient ces attributs. Hors j viens de réaliser que c'est une très mauvaise idée, car ces attributs pourraient se trouver modifiés par le traitement d'une requête pendant le traitement d'une autre.
D'où ma question : rassurez-moi, y'a-t-il un synchronized quelque part, ou est-ce que c'est à moi de le mettre ?




 
C'est à toi se syncrhoniser les accès. C'est pour ca que les attributs déclarés au sein de la méthode service (ou doGet/doPost) son thread safe et pas les attributs d'instance. De plus, ton app server peut très bien faire du pooling de servlet sans te demander ton avis !!! Et créer X instances de ta servlet et distribuer la charge selon les requetes qui arrivent sur le serveur.
 
Conclusion: tu dois gérer la concurence et pas au sein d'une instance de la servlet mais au sein de ton servlet container (via des helpers synchronisés ou autre)


---------------
Just because you feel good does not make you right
n°186765
El_gringo
Posté le 31-07-2002 à 09:31:18  profilanswer
 

DarkLord a écrit a écrit :

 
 
 [:tapai]  




 
hé... calme ! j'ai dit j'crois. On a encore l'droit de se planter ?

n°186766
R3g
fonctionnaire certifié ITIL
Posté le 31-07-2002 à 09:32:12  profilanswer
 

el_gringo a écrit a écrit :

J'crois que t'as une instance de servlet par requete client !




ah oui non ca j'en suis sur : la servlet est instanciée à la première requête qui lui est addressée, et traite toutes les suivantes ; tu vois pas le bordel si il fallait instancier un objet à chaque requête et le détruire ensuite ?

n°186767
El_gringo
Posté le 31-07-2002 à 09:34:28  profilanswer
 

R3g a écrit a écrit :

 
ah oui non ca j'en suis sur : la servlet est instanciée à la première requête qui lui est addressée, et traite toutes les suivantes ; tu vois pas le bordel si il fallait instancier un objet à chaque requête et le détruire ensuite ?




 
C bon, Dark me l'as déja signalé. En toute délicatesse, comme il sait le faire !

n°186768
R3g
fonctionnaire certifié ITIL
Posté le 31-07-2002 à 09:35:32  profilanswer
 

DarkLord a écrit a écrit :

 
C'est pour ca que les attributs déclarés au sein de la méthode service (ou doGet/doPost) son thread safe et pas les attributs d'instance.



Ok donc ca veut dire que si je déclare les atributs dans la methode service et que je les passe ensuite aux autres méthodes, là j'ai pas de problème. En fait c'est l'appel à service() qui est synchronized ?
 

Darklord a écrit a écrit :

 
Conclusion: tu dois gérer la concurence et pas au sein d'une instance de la servlet mais au sein de ton servlet container (via des helpers synchronisés ou autre)




Tu peux expliquer "helpers synchronsés" stp ?

n°186769
darklord
You're welcome
Posté le 31-07-2002 à 09:36:57  profilanswer
 

sinon si tu veux pas te casser la tete il y a une astuce
 

Citation :


HTTP servlets are typically capable of serving multiple clients concurrently. If the methods in your servlet that do work for clients access a shared resource, then you can handle the concurrency by creating a servlet that handles only one client request at a time. (You could also synchronize access to the resource, a topic that is covered in this tutorial's lesson on threads.)  
 
To have your servlet handle only one client at a time, have your servlet implement the SingleThreadModelinterface in addition to extending the HttpServlet class.  
 
Implementing the SingleThreadModel interface does not involve writing any extra methods. You merely declare that the servlet implements the interface, and the server makes sure that your servlet runs only one service method at a time.  
 
For example, the ReceiptServlet accepts a user's name and credit card number, and thanks the user for their order. If this servlet actually updated a database, for example one that kept track of inventory, then the database connection might be a shared resource. The servlet could either synchronize access to that resource, or it could implement the SingleThreadModel interface. If the servlet implemented the interface, the only change in the code from the previous section is the one line shown in bold:  
 
    public class ReceiptServlet extends HttpServlet
                                implements SingleThreadModel {
 
        public void doPost(HttpServletRequest request,
                           HttpServletResponse response)
     throws ServletException, IOException {
                ...
        }
        ...
    }
 


---------------
Just because you feel good does not make you right
mood
Publicité
Posté le 31-07-2002 à 09:36:57  profilanswer
 

n°186770
darklord
You're welcome
Posté le 31-07-2002 à 09:37:48  profilanswer
 

el_gringo a écrit a écrit :

 
 
C bon, Dark me l'as déja signalé. En toute délicatesse, comme il sait le faire !




 
T'as pas besoin de faire ton frustré ou de me faire passer pour le méchant. Quand on sait pas, on se tait :)
 

Citation :


a mon avis tu t'inquiètes pour rien


 
heureusement qu'il ne te croit pas sur parole :)


---------------
Just because you feel good does not make you right
n°186775
darklord
You're welcome
Posté le 31-07-2002 à 09:40:45  profilanswer
 

R3g a écrit a écrit :

 
Ok donc ca veut dire que si je déclare les atributs dans la methode service et que je les passe ensuite aux autres méthodes, là j'ai pas de problème. En fait c'est l'appel à service() qui est synchronized ?
 
Tu peux expliquer "helpers synchronsés" stp ?




 
L'appel à service n'est pas synchronisé mais chaque fois que tu vas entrer dans la méthode (meme si c'est deux threads en meme temps qui entre dans la meme méthode) les variables définies dans la méthode service (ou doGet/doPost c'est pareil) sont internes à l'appel et donc réservé à cet appel. Pas besoin de synchronisation, elles sont thread-safe de facto!
 
Pour le helpers, il s'agit simplement d'une classe java standard (et oui on est pas obligé que d'utiliser des servlets dans un app server :) ) qui synchronise ta resource. Si tu dois augmenter un compteur par exemple, ta servlet appelle un helper qui s'occupe de te donner accès si aucune autre n'instance n'est en train de bosser dessus etc ...
 
Si tu fais SingleThreadModel ca peut diminuer les perfs dans le cas de requete en cascade c'est à toi de voir.


Message édité par darklord le 31-07-2002 à 10:44:19

---------------
Just because you feel good does not make you right
n°186777
El_gringo
Posté le 31-07-2002 à 09:42:27  profilanswer
 

DarkLord a écrit a écrit :

 
 
T'as pas besoin de faire ton frustré ou de me faire passer pour le méchant. Quand on sait pas, on se tait :)
 

Citation :


a mon avis tu t'inquiètes pour rien


 
heureusement qu'il ne te croit pas sur parole :)




 
Quand on ne sais pas, on doit parler au contraire, et dire ce qu'on pense, tout en pondérant son discours d'avertissements ("je crois", "je suis pas sur", ...)
ça s'appel une hypothèse, c ça qui fait avancer le monde.
 :fuck:

n°186778
R3g
fonctionnaire certifié ITIL
Posté le 31-07-2002 à 09:42:55  profilanswer
 

DarkLord a écrit a écrit :

 
 
L'appel à service n'est pas synchronisé mais chaque fois que tu vas entrer dans la méthode (meme si c'est deux threads en meme temps qui entre dans la meme méthode) les variables définies dans la méthode service (ou doGet/doPost c'est pareil) sont internes à l'applet et donc réservé à cet appel. Pas besoin de synchronisation, elles sont thread-safe de facto!
 
Pour le helpers, il s'agit simplement d'une classe java standard (et oui on est pas obligé que d'utiliser des servlets dans un app server :) ) qui synchronise ta resource. Si tu dois augmenter un compteur par exemple, ta servlet appelle un helper qui s'occupe de te donner accès si aucune autre n'instance n'est en train de bosser dessus etc ...
 
Si tu fais SingleThreadModel ca peut diminuer les perfs dans le cas de requete en cascade c'est à toi de voir.




Ok merci pour tout !
Effectivement je trouve SingleThreadModel un peu bourrin pour mon cas, mais c'est toujours bon à savoir.

n°186779
darklord
You're welcome
Posté le 31-07-2002 à 09:43:06  profilanswer
 

el_gringo a écrit a écrit :

 
 
Quand on ne sais pas, on doit parler au contraire, et dire ce qu'on pense, tout en pondérant son discours d'avertissements ("je crois", "je suis pas sur", ...)
ça s'appel une hypothèse, c ça qui fait avancer le monde.
 :fuck:  




 
 
T'en redemande y a l'air  [:tapai]  
 
 [:rofl]


---------------
Just because you feel good does not make you right
n°186781
R3g
fonctionnaire certifié ITIL
Posté le 31-07-2002 à 09:44:04  profilanswer
 

Ah non, vous allez pas vous battre sur mon topic hein  :non:

n°186786
El_gringo
Posté le 31-07-2002 à 09:48:22  profilanswer
 

DarkLord a écrit a écrit :

 
 
 
T'en redemande y a l'air  [:tapai]  
 
 [:rofl]  




 
Et, Darklord ou non, je clamerai mes hypothèses de par le monde !! :bounce:  :bounce:  :bounce:  :bounce:

n°186795
darklord
You're welcome
Posté le 31-07-2002 à 09:52:05  profilanswer
 

R3g a écrit a écrit :

Ah non, vous allez pas vous battre sur mon topic hein  :non:  




 
c'est une vieille habitude :)


---------------
Just because you feel good does not make you right
n°186799
El_gringo
Posté le 31-07-2002 à 09:53:55  profilanswer
 

Après chaque topic, 'faut qu'on se mette sur la gueule, on peut pas résister !
Tient Dark, prends ça dans ta gueule  :fuck:


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Java

  [java-servlet] question sur la conccurence

 

Sujets relatifs
[Java-Jdbc] requêtes SQL n'aboutissant pas ![PHP] je ne capte pas !! [RESOLU] MERCI Mais ya encore une question !
de C++ vers Java : le mot clé "const"( en C++)Juste une question comme ca?
lancement d'un servlet[PHP] Peut être une question con ;) mettre les liens en variable ???
generer une page HTML en java[oracle] TRIGGERS... question tres simple pour ceux qui connaissent..
[Java] Requete au proxy sans resolution DNS[HTML] question toute conne ..
Plus de sujets relatifs à : [java-servlet] question sur la conccurence


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR