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

  FORUM HardWare.fr
  Programmation
  Java

  Gestion d'évènements

 
 


 Mot :   Pseudo :  
 
 Page :   1  2
Page Suivante
Page Précédente
Bas de page 
Auteur Sujet :

Gestion d'évènements

n°191923
El_gringo
Posté le 08-08-2002 à 10:56:28  profilanswer
 

Je connais pour ainsi dire, rien du tout, à la gestion des evênements en Java.
Là, je suis en train d'écrire une classe. Je voudrais que, quand on change certains trucs, un listener de ma création puisse capter des messages.
L'élément qu'y me manque, c'est : comment lancer un évènement ?

mood
Publicité
Posté le 08-08-2002 à 10:56:28  profilanswer
 

n°191925
darklord
You're welcome
Posté le 08-08-2002 à 11:02:35  profilanswer
 

Code :
  1. /**
  2. * The listener interface for receiving notification about XXXEvent
  3. */
  4. public interface XXXEventListener {
  6.     /**
  7.      * Invoked when an XXXEvent occured
  8.      */
  9.     public void xxxEventPerformed(XXXEvent e);
  10. }
  13. /**
  14. * Gives high level details about an XXXEvent.
  15. * @author Stephane Nicoll
  16. */
  17. public class XXXEvent {
  19.     protected XXXServer m_source = null;
  21.     /**
  22.      * Constructs an new XXXEvent with the source that generates this event.
  23.      */
  24.     protected IVREvent(XXXServer source) throws IllegalArgumentException {
  25.         if (source == null)
  26.             throw new IllegalArgumentException("null value not allowed" );
  27.         m_source = source;
  28.     }
  30.     /**
  31.      * Returns the source of this event.
  32.      */
  33.     public XXXServer getSource() {
  34.         return m_source;
  35.     }
  36. }


 
Ensuite dans ton XXXServer (en gros l'objet qui dois générer des évenements, tu as un truc du genre
 

Code :
  1. public class XXXMyServer implements XXXServer {
  2. //par exemple
  4. ...
  6.    /**
  7.     * The listeners
  8.     */
  9.    protected ArrayList listeners = null;
  12.    /**
  13.     * Adds the specified XXXEventListener to receive events from this XXXServer.
  14.     * If listener l is null, no exception is thrown and no action is performed.
  15.     * @param l
  16.     * The XXXEventListener to add
  17.     */
  18.     public void addXXXEventListener(XXXEventListener l) {
  19.        if (l == null)
  20.            return;
  21.        if (listeners.indexOf(l) == -1)
  22.            listeners.add(l);
  23.     }
  25.    /**
  26.     * Fires an event to all registered listeners.
  27.     */
  28.    private synchronized void firexxxEventPerformed() {
  29.        XXXEvent ev = new XXXEvent(this);
  30.        Iterator i = listeners.iterator();
  31.        while (i.hasNext()) {
  32.            XXXEventListener l = (XXXEventListener) i.next();
  33.            l.xxxEventPerformed(ev);
  34.        }
  35.    }
  36. ...
  37. }


 
 
Ensuite dans la classe qui doit recevoir l'evenements tu lui fais implémenter XXXEventListener et lorsque tu l'instancies ou que tu la configures tu appelles addXXXEventListener(this) (ou l'objet qui implémentes le listener) sur le XXXServer dont tu veux recevoir des évenements.
 
Clair?


Message édité par darklord le 08-08-2002 à 11:06:47

---------------
Just because you feel good does not make you right
n°191927
darklord
You're welcome
Posté le 08-08-2002 à 11:07:35  profilanswer
 

ici mon XXXEvent n'étends pas l'event générique et ca tu peux le faire si les méthodes incluses t'intéresse ...


---------------
Just because you feel good does not make you right
n°191937
benou
Posté le 08-08-2002 à 11:19:48  profilanswer
 

histoire de rappeler le bon vieux temps ou je rajoutait toujours mon grain de sel à ce que disait dark, tu peux utiliser un Set pour stocker les listeners (genre java.util.HashSet) et t'assurer qu'ils soient uniques
 
et si je me trompe pas, il faut aussi que le addEvent listener soit synchronized sinon ca va planter si tu en ajoute un pendant qu'il est en train de balancer les évenements.
 

n°191945
darklord
You're welcome
Posté le 08-08-2002 à 11:25:08  profilanswer
 

ah oui. C'est juste ca :)
 
merci pour l'info


---------------
Just because you feel good does not make you right
n°191963
darklord
You're welcome
Posté le 08-08-2002 à 11:55:48  profilanswer
 

ceci dit benou,  
 
HashSet ne sert vraiment à rien parce que là seule méthode qui le remplit prend comme argument un XXXEventListener
 
synchronized n'est pas requis puisque la méthode qui génère les évenemtns est synchronisés sur l'objet. A moins qu'il y ait ce fameux machin qu'une méthode non synchronisée pouvait foutre le bordel sur un objet qui execute une méthode synchronisée. Mais j'ai pas vraiment capté ce principe donc si tu as des infos ;)


---------------
Just because you feel good does not make you right
n°192061
El_gringo
Posté le 08-08-2002 à 14:34:24  profilanswer
 

Ha, génial, on peut pas faire plus claire.
Merci Dark  :hello:

n°192066
benou
Posté le 08-08-2002 à 14:41:51  profilanswer
 

DarkLord a écrit a écrit :

ceci dit benou,  
HashSet ne sert vraiment à rien parce que là seule méthode qui le remplit prend comme argument un XXXEventListener



:??: ben c'est pas ca le problème, c'est juste que c'est lpus logique de mettre un Set qu'une Collection puisque tu veux qu'il n'y ait pas 2 fois le même event qui soit enregistré : t'auras pas besoin de faire le test pour savior si il est déjà dedans ...
 

Citation :


synchronized n'est pas requis puisque la méthode qui génère les évenemtns est synchronisés sur l'objet. A moins qu'il y ait ce fameux machin qu'une méthode non synchronisée pouvait foutre le bordel sur un objet qui execute une méthode synchronisée. Mais j'ai pas vraiment capté ce principe donc si tu as des infos ;)


 
ben si c'est obligé : c'est la méthode qui est synchronized.
 
La règle avec les synchronized c'est que tu ne pourra pas avoir 2 méthodes synchronized appelée en même temps sur la même instance => tu peux très bien appeler le addListener pendant l'executino du fireEvent ce qui va altérer ta ArrayList => l'Iterator sera dans un état instable => tu vas te manger une Error à des moments assez aléatoire ...
 
la solution c'est soit de mettre la méthode addListener en synchronized soit de vérouiller la liste pendant qu'on  s'en sert, ce qui est d'ailleur plus propre :
 
 

Code :
  1. protected Set listeners = new HashSet();
  2.  
  3.    public void addXXXEventListener(XXXEventListener l) {
  4.       if (l == null)
  5.           return;
  6.       synchronized (listeners) {
  7.           listeners.add(l);
  8.       }
  9.    }
  11.   /**  
  12.    * Fires an event to all registered listeners.  
  13.    */
  14.   private void firexxxEventPerformed() {
  15.       XXXEvent ev = new XXXEvent(this);
  16.       synchronized (listeners) {
  17.          Iterator i = listeners.iterator();
  18.          while (i.hasNext()) {
  19.             XXXEventListener l = (XXXEventListener) i.next();
  20.             l.xxxEventPerformed(ev);
  21.          }
  22.       }
  23.   }

n°192075
benou
Posté le 08-08-2002 à 14:46:42  profilanswer
 

DarkLord a écrit a écrit :

. A moins qu'il y ait ce fameux machin qu'une méthode non synchronisée pouvait foutre le bordel sur un objet qui execute une méthode synchronisée.



là ce dont tu parles c'est les problèmes d'interblocage (je crois que c'est comme ca que ca s'apelle). C'est quand tu apelles une méthode blocante (vérrouillée) alors que tu es toi même à l'intérieur d'un autre verrou sur autre instance d'objet : ca fait que les 2 s'attende mutuellement => blocage
 
fait une recherche sur google sur le problème des philosophes ou des producteurs-consomateurs en programation parallèle si ca t'intéresses.
(ca va rapeller des trucs à chapi si il traine dans le coin)

n°192076
darklord
You're welcome
Posté le 08-08-2002 à 14:47:04  profilanswer
 

:jap:


---------------
Just because you feel good does not make you right
mood
Publicité
Posté le 08-08-2002 à 14:47:04  profilanswer
 

n°192138
chapi456
Posté le 08-08-2002 à 16:06:35  profilanswer
 

non ... ca me rappelle rien du tout  :kaola:  
En anglais, ca s'appelle le DeadLock ! mais ca ne correspond pas vraiment a la problematique du prod-conso !
Le prod conso c'est exactement le meme probleme qu'avec les listener : avec un consommateur (le déclencheur d'événements) et le producteur (l'événements et son ajout dans la liste des évenements a traiter)!
Tiens, pour la peine, je me refile un  :jap:  

n°192164
veryfree
Posté le 08-08-2002 à 16:29:03  profilanswer
 

chapi456 a écrit a écrit :

non ... ca me rappelle rien du tout  :kaola:  
En anglais, ca s'appelle le DeadLock ! mais ca ne correspond pas vraiment a la problematique du prod-conso !
Le prod conso c'est exactement le meme probleme qu'avec les listener : avec un consommateur (le déclencheur d'événements) et le producteur (l'événements et son ajout dans la liste des évenements a traiter)!
Tiens, pour la peine, je me refile un  :jap:  




 
multinick de qui?

n°192222
benou
Posté le 08-08-2002 à 17:04:42  profilanswer
 

veryfree a écrit a écrit :

 
multinick de qui?




bha de personne ... c'est chapi quoi ...

n°192248
El_gringo
Posté le 08-08-2002 à 17:21:39  profilanswer
 

Et, si je décide de me passer de XXXMyServer, et d'inclure ses méthodes dans l'unique objet qui pourra lancer les evenements XXX (comme ça a l'air d'avoir été fait pour les Button Awt par exemple).
c "deprecated" cette façon de faire ?

n°192260
darklord
You're welcome
Posté le 08-08-2002 à 17:34:30  profilanswer
 

bin c'est le cas dans mon exemple. Si tu veux une analogie, le XXXServer c'est un JComponent par exemple et le MyXXXServer c'est un JButton
 
Y a aucune différence  :heink:
 
Et puis tout dépend de ce que tu veux générer comme évenement. Si la source n'a pas d'importance bin tu change ton XXXEvent pour qu'il te file d'autre info (comme un objet quelconque, une String ou d'autre truc). Tout  dépend l'évenement que tu veux transmettre ...


Message édité par darklord le 08-08-2002 à 17:35:36

---------------
Just because you feel good does not make you right
n°192268
El_gringo
Posté le 08-08-2002 à 17:38:47  profilanswer
 

DarkLord a écrit a écrit :

bin c'est le cas dans mon exemple. Si tu veux une analogie, le XXXServer c'est un JComponent par exemple et le MyXXXServer c'est un JButton
 
Y a aucune différence  :heink:
 
Et puis tout dépend de ce que tu veux générer comme évenement. Si la source n'a pas d'importance bin tu change ton XXXEvent pour qu'il te file d'autre info (comme un objet quelconque, une String ou d'autre truc). Tout  dépend l'évenement que tu veux transmettre ...




 
Ha, ok.
Vu vu le nom que t'avais donné à MyXXXServer, j'croyais que t'avais imaginé un truc du style des PropertyChangeSupport. Tu vois ce que j'veux dire ?

n°192283
darklord
You're welcome
Posté le 08-08-2002 à 17:47:01  profilanswer
 

oulalal comme tu y vas toi :)
 
Non je pensais pas si loin. D'ailleurs c'est histoire de XXXServer et MyXXXServer qui compliquait inutilement le problème ... :(


---------------
Just because you feel good does not make you right
n°192293
El_gringo
Posté le 08-08-2002 à 17:51:39  profilanswer
 

DarkLord a écrit a écrit :

oulalal comme tu y vas toi :)
 
Non je pensais pas si loin. D'ailleurs c'est histoire de XXXServer et MyXXXServer qui compliquait inutilement le problème ... :(




 
Mais g pas été attentif, j'aurais pu voir que dans ta méthode fireXXXEventPerformed, quand tu crés l'évènement, t'y attaches "this".
Pour un truc style PropertyChangeSupport, j'imagine que l'évènement prend pas this dans son constructeur. ça aurait pas trop de sens.
 
EDIT : G bon, g vérifié !  :sol:


Message édité par El_gringo le 08-08-2002 à 17:51:49
n°192295
El_gringo
Posté le 08-08-2002 à 17:53:14  profilanswer
 

Merci en tout cas. C'était interressant en plus d'être utile.
(la partie des "synchronized", c pas vraiment compris, ms c pas grave, ça viendra + tard. ¨Pour ça, j'vais recopier bêtement :D

n°192299
darklord
You're welcome
Posté le 08-08-2002 à 17:56:29  profilanswer
 

synchronized te permet de mettre un lock sur un objet. L'idée dans ce cas ci c'est que personne ne peut ajouter un listener pendant que tu parcours la liste pour envoyer les évenement aux clients.
 
donc en faisant
 

Code :
  1. synchronized(listeners) {
  2.   // Tout le code qui est execute ici a un verrou sur l'objet qui s'appelle listeners (une ArrayList en l'occurence). Si un autre objet veut faire qqch sur l'objet il devra attendre que ce bloc se termine. De cette façons la méthode qui ajoute un listener serait bloquée si l'objet était en train d'executer ce bout de code.  
  3. }


 
Ne pas utiliser ca a tout bout de champ parce que ca détruit les perfs ... C'est la raison principale qui fait que Vector est un Container très lent


Message édité par darklord le 08-08-2002 à 17:56:38

---------------
Just because you feel good does not make you right
n°192369
benou
Posté le 08-08-2002 à 18:58:29  profilanswer
 

juste une précision :

synchronized(listeners) {  
 // Tout le code qui est execute ici a un verrou sur l'objet qui s'appelle listeners (une ArrayList en l'occurence). Si un autre objet veut faire qqch sur l'objet [g]il devra attendre que ce bloc se termine[/g]. De cette façons la méthode qui ajoute un listener serait bloquée si l'objet était en train d'executer ce bout de code.  
}


ce que j'ai mit en gras c'est pas tout à fait vrai : tu pourras encore manipuler l'objet synchronisé même si le bloc n'est pas terminé. Par contre, tu ne pourra pas entrer à nouveau dans un bloc synchronisé sur le même objet.
 
Je suis clair là ?
 
edit : pkoi ca vaut pas se mettre en gras ??? :(


Message édité par benou le 08-08-2002 à 18:59:40
n°192682
El_gringo
Posté le 09-08-2002 à 09:05:50  profilanswer
 

benou a écrit a écrit :

juste une précision :

synchronized(listeners) {  
 // Tout le code qui est execute ici a un verrou sur l'objet qui s'appelle listeners (une ArrayList en l'occurence). Si un autre objet veut faire qqch sur l'objet [g]il devra attendre que ce bloc se termine[/g]. De cette façons la méthode qui ajoute un listener serait bloquée si l'objet était en train d'executer ce bout de code.  
}


ce que j'ai mit en gras c'est pas tout à fait vrai : tu pourras encore manipuler l'objet synchronisé même si le bloc n'est pas terminé. Par contre, tu ne pourra pas entrer à nouveau dans un bloc synchronisé sur le même objet.
 
Je suis clair là ?
 
edit : pkoi ca vaut pas se mettre en gras ??? :(




 
Ouais, c clair.
Mais alors dans notre cas, il faudra aussi synchroniser listeners dans la méthode d'ajout !  
Un synchronize qui n'apparait qu'a un seul endroit dans un objet n'aurait pas de sens (enfin, si l'attribut synchronisé ne peut pas être accèdé par l'extérieur de l'objet).

n°192684
benou
Posté le 09-08-2002 à 09:08:12  profilanswer
 

El_Gringo a écrit a écrit :

 
 
Ouais, c clair.
Mais alors dans notre cas, il faudra aussi synchroniser listeners dans la méthode d'ajout !  
Un synchronize qui n'apparait qu'a un seul endroit dans un objet n'aurait pas de sens (enfin, si l'attribut synchronisé ne peut pas être accèdé par l'extérieur de l'objet).




ouais c'est ca ! et c'est ce que j'ai fait : regarde le code que j'avais donné.
 
et si ca a un sens : ca fait que 2 thread ne peuvent pas executer en même temps la méthode synchronisée

n°192686
El_gringo
Posté le 09-08-2002 à 09:12:29  profilanswer
 

benou a écrit a écrit :

 
ouais c'est ca ! et c'est ce que j'ai fait : regarde le code que j'avais donné.
 
et si ca a un sens : ca fait que 2 thread ne peuvent pas executer en même temps la méthode synchronisée  




 
Ha ouais, j'avais pas vu.
 
Tient, j'avais pas pensé pour les threads. Mais de toute façon, synchroniser des attrubuts (ou des méthodes), ça n'a de sens que dans un cadre multi thread, non !?
Parce qu'en mono thread, le code n'est exécuté ne se passe qu'a un endroit à la fois (enfin, vous m'comprenez quoi !).
A moins que... certaines classes du JDK ou d'autres lib utilisent parfois plusieurs threads ?

n°192687
chapi456
Posté le 09-08-2002 à 09:18:15  profilanswer
 

y'a aussi dans le cas ou tu fais un serveur avec plusieurs clients (sans vraiment mettre en place de multi thread)  
La tu pourrais avoir pas mal de probleme (surtout que comme par hazard, c'est toujours au MEME moment que 2 bozots vont faire la meme manip !
donc synchronized :  :love:  
 
P.S. : Benou : on prend le grand lit chez loic ?  :pt1cable: (ou comment casser une reputation ....)

n°192699
benou
Posté le 09-08-2002 à 09:37:42  profilanswer
 

El_Gringo a écrit a écrit :

 
 Mais de toute façon, synchroniser des attrubuts (ou des méthodes), ça n'a de sens que dans un cadre multi thread, non !?




ben oui mais par exemple, dès que tu fais des interfaces graphiques c'est multi-threadé !

n°192702
benou
Posté le 09-08-2002 à 09:39:01  profilanswer
 

chapi456 a écrit a écrit :

 
P.S. : Benou : on prend le grand lit chez loic ?  :pt1cable: (ou comment casser une reputation ....)




heu .... je plus très sur de vouloir aller aider loic, là d'un coup ... ;)

n°192740
El_gringo
Posté le 09-08-2002 à 10:59:00  profilanswer
 

benou a écrit a écrit :

 
ben oui mais par exemple, dès que tu fais des interfaces graphiques c'est multi-threadé !  




 
Ouais, donc du coup 'faut tjs penser multi thread. Surout que là je suis ds l'cadre d'une servlet.
J'ai compris comment ça marche synchronized (fini les mutex si g bien compris ! Y vont pas me manquer ceux là :D ).
Mais par contre, je vois pas à quel moment en mettre, et ou !
Parce que j'aurais envie d'en mettre partout finalement...

n°192747
benou
Posté le 09-08-2002 à 11:06:34  profilanswer
 

ben uniquement sur les objets qui sont partagés ...
 
dans le cadre des servlets faut faire attention parce que si t'en mets partout tu vas avior des temps de réopnses désastreux dès que tu auras plusieurs accès simultanés ...
 
pour les servlets, tu sera par exemple obligé d'en mettre si tu as un attribut de ta servlet qui est une arrayList par exemple et qu'elle est amenée à changer pendant que d'autres la lisent ...
 
 
Mais ce genre de trucs peut être réglé en fesant une copie de la ArrayList : si à un moment tu dois ajouter un élément, plutot que de faire un add(), tu fais une copie de la arraylist, tu fais un add sur la copie et tu remplace l'original par la copie. Comme la copie de référence est une opération atomoique, le problème ne se pose pas :
 
version de base :

Code :
  1. private List uneListePartagee;
  2. //...
  3. private void modifList() {
  4.    synchronized(uneListePartagee) {
  5.       uneListePartagee.add("machin" );
  6.    }
  7. }


 
version sans synchronized :

Code :
  1. private List uneListePartagee;
  2. //...
  3. private void modifList() {
  4.    List tmp = new ArrayList(uneListePartagee); //copie
  5.    tmp.add("machin" );
  6.    this.uneListePartagee = tmp; // opération atomique => pas de probleme
  7. }

n°192754
El_gringo
Posté le 09-08-2002 à 11:13:05  profilanswer
 

Mais, par exemlpe dans ma servlet, c quoi un objet partagé !?
une opération atomique c quoi ? c synchronisé automatiquement ?

n°192761
benou
Posté le 09-08-2002 à 11:22:58  profilanswer
 

ben ca tu devrais le savoir :o
 
ta servlet n'est instancié qu'une seule fois par le moteur de servlet : pour chaque requête vers la servlet, c'est toujours le même objet qui est appelé.
 
Donc, si plusieurs client appellent la même page en même temps, la servlet executera en parallèle (dans différents threads) plusieurs fois la méthode doGet ou doPost. Il n'y a pas de problème pour tous ls objets que tu vas déclarer à l'intérieur de ces méthodes car ils seront "isolés" (les autres thread ne les connaîtront pas), par contre, les attributs de ton objet servlet, eux ils sont accessible par ta méthode doGet ou doPost, donc ils sont accessible en même temps par plusieurs thread. Ils sont donc "partagés" avec les problèmes que ca pose ...
 
une opération atomique, c'est juste une instruction qui sera forcément fait "en un coup" par la machine. Dans ces cas là, tu es sur que tu n'auras pas de problème d'execution parallèles
Dans le cas de copie de référence, c'est atomique puisque ca correspond à une copie d'adresse mémoire.  
 
quelques exemples :

Code :
  1. i = 1; // atomique
  2. Sring s = "coucou" // atomique
  3. String s2 = "beuh" // atomique
  4. s = s2 // atomique
  6. i = i + 1 // pas atomique
  7. s = s + s2 // pas atomique
  9. Vector v = new Vector();
  10. Vector v2 = new Vector();
  11. v.add("coucou" ); // pas atomique
  12. v = v2; // atomique

n°192764
--greg--
Posté le 09-08-2002 à 11:27:39  profilanswer
 

[:blueflag]

n°192765
benou
Posté le 09-08-2002 à 11:28:13  profilanswer
 

--greg-- a écrit a écrit :

[:blueflag]




:)

n°192768
--greg--
Posté le 09-08-2002 à 11:29:37  profilanswer
 

benou a écrit a écrit :

 
:)



:jap:
une bonne petite revision sympa:)

n°192806
El_gringo
Posté le 09-08-2002 à 11:40:44  profilanswer
 

benou a écrit a écrit :

ben ca tu devrais le savoir :o
 
ta servlet n'est instancié qu'une seule fois par le moteur de servlet : pour chaque requête vers la servlet, c'est toujours le même objet qui est appelé.
 
Donc, si plusieurs client appellent la même page en même temps, la servlet executera en parallèle (dans différents threads) plusieurs fois la méthode doGet ou doPost. Il n'y a pas de problème pour tous ls objets que tu vas déclarer à l'intérieur de ces méthodes car ils seront "isolés" (les autres thread ne les connaîtront pas), par contre, les attributs de ton objet servlet, eux ils sont accessible par ta méthode doGet ou doPost, donc ils sont accessible en même temps par plusieurs thread. Ils sont donc "partagés" avec les problèmes que ca pose ...
 
une opération atomique, c'est juste une instruction qui sera forcément fait "en un coup" par la machine. Dans ces cas là, tu es sur que tu n'auras pas de problème d'execution parallèles
Dans le cas de copie de référence, c'est atomique puisque ca correspond à une copie d'adresse mémoire.  
 
quelques exemples :

Code :
  1. i = 1; // atomique
  2. Sring s = "coucou" // atomique
  3. String s2 = "beuh" // atomique
  4. s = s2 // atomique
  6. i = i + 1 // pas atomique
  7. s = s + s2 // pas atomique
  9. Vector v = new Vector();
  10. Vector v2 = new Vector();
  11. v.add("coucou" ); // pas atomique
  12. v = v2; // atomique






 
Super bien expliqué, merci Benou !
 
Pour les objets partagés, en fait je le savais. Ms j'y ai pas pensé sur le coup. Et j'avais pas imaginé les conséquences que ça pouvait avoir. J'vais ajouter qqs synchronized ds mon code.
Et donc, dans une servlet qui est pas explicitement multi thread, les seuls objets "partagés" sont les attributs de ma classe servlet, c ça ?
 
opération atomique, ouais, j'aurais pu m'en douter !
Ms on devrait appaler ça des opération quarkiques, l'image serait plus juste ! :D

n°192814
benou
Posté le 09-08-2002 à 11:44:14  profilanswer
 

El_Gringo a écrit a écrit :

 
Super bien expliqué, merci Benou !




:jap:
 

Citation :

Et donc, dans une servlet qui est pas explicitement multi thread, les seuls objets "partagés" sont les attributs de ma classe servlet, c ça ?


une servlet est TOUJOURS multithreadée !
 
et non, y a pas forcément que les attributs ... y a aussi tous les objets communs à ton application (dans le ServletContext) ou tes les objets statiques, etc ...
 
et évite de foutre des synchronized partout. Imagine un peu les conséquences !

n°192824
--greg--
Posté le 09-08-2002 à 11:49:27  profilanswer
 

benou a écrit a écrit :

 
une servlet est TOUJOURS multithreadée !
 



:non: "implements SingleThreadModel"
ou qqchose comme ça :ange:


Message édité par --greg-- le 09-08-2002 à 11:49:40
n°192834
El_gringo
Posté le 09-08-2002 à 11:55:22  profilanswer
 

benou a écrit a écrit :

 
:jap:
 

Citation :

Et donc, dans une servlet qui est pas explicitement multi thread, les seuls objets "partagés" sont les attributs de ma classe servlet, c ça ?


une servlet est TOUJOURS multithreadée !
 
et non, y a pas forcément que les attributs ... y a aussi tous les objets communs à ton application (dans le ServletContext) ou tes les objets statiques, etc ...
 
et évite de foutre des synchronized partout. Imagine un peu les conséquences !




 
Je voulais dire, si on cré pas des thread autres que ceux gérés par le moteur de servlet.
 
J'imagine les conséquences. J'imagine. J'ai déja été confronté à ça. g vu tourner une appli ou tous les accès BD étaient synchronizés (c pas moi qui l'ai faite !). c'était terrible !

n°192842
benou
Posté le 09-08-2002 à 11:58:23  profilanswer
 

--greg-- a écrit a écrit :

 :non: "implements SingleThreadModel"
ou qqchose comme ça :ange:




:??: je connais pas ca ... t'es sur de ton coup là ?
 
et puis bon, tu peux facilement monothreader ta servlet en synchronisant la méthode service mais c'est vraiment imonde !

n°192844
darklord
You're welcome
Posté le 09-08-2002 à 11:59:05  profilanswer
 

vi vi si tu implémentes SingleThreadModel c'est une seule instance et un seul appel à la fois


---------------
Just because you feel good does not make you right
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Suivante
Page Précédente
Haut de page 

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

  Gestion d'évènements

 

Sujets relatifs
gestion d'ecran sous wingestion de la mémoire ?
Gestion d'événements et vous, vous faites comment ?cherche des nfos sur la gestion d'erreur en ASP avec SQL
[Access] Pb de gestion de droit sous XP[VC++] gestion des evenements
[JAVA] Gestion des évênementsGestion des évènements avec les MFC
Gestion des évènements avec les MFCGestion des évènements avec les MFC
Plus de sujets relatifs à : Gestion d'évènements

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.142 secondes

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