Discussion :

[metalcoyote]

Bonjour,

J'ai fait une appli qui au lancement de celle-ci cree plusieurs servers. (serverSocket), chaqun de ces serveur peut donc accpeter des connections et donc creer plusieurs threads.
Le souci est que tous ces serveurs auraient besoin de "communiquer" entre eux, ou pouvoir consulter tous les memes variables. Creer une partie "commune" en gros.
Je pensai donc creer une classe avec des valeurs static, et mettre dedan touts les champs que je voudrai rendre accessible a mes differents serveurs...
les server accederont/modifiront ces val de facon synchronisee.

Qu'est ce que vous en pensez ?

[iohack]

C'est une façon de faire (c'est un peu comme cela que marchent les IPC)... Attention à la synchronisation !
Sinon tu peux utiliser RMI également.

[metalcoyote]

OK merci du tuyau !

edit: Il n'y aura pas de prob de synchronisation avec RMI ?

[deltree]

Bonjour,
le RMI c'est surtout entre jvm différentes.
plutôt que d'avoir plusieurs éléments statiques, mieux vaut un singleton (basé sur un seul statique) qui contient des attributs d'instances (normaux).
ça permet d'avoir plus de polymorphisme sur ta classe au besoin (pas d'override sur les static) et éventuellement d'avoir plusieurs instance le jour ou ce n'est plus un singleton.

la synchronisation il suffit de le faire à l'écriture (sur tes set()) et c'est bon.

[metalcoyote]

mieux vaut un singleton (basé sur un seul statique) qui contient des attributs d'instances (normaux)

Merci mais je vois pas trop ce que c'est
t'as une petite demo sous la main

[Duc Lebowski]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class Singleton {
     /**
      * Création de l'instance au niveau de la variable.
      */
     private static final Singleton INSTANCE = new Singleton();
 
     /**
      * La présence d'un constructeur privé supprime
      * le constructeur public par défaut.
      */
     private Singleton() {}
 
     /**
      * Dans ce cas présent, le mot-clé synchronized n'est pas utile.
      * L'unique instanciation du singleton se fait avant
      * l'appel de la méthode getInstance(). Donc aucun risque d'accès concurrents.
      * Retourne l'instance du singleton.
      */
     public static Singleton getInstance() {
         return INSTANCE;
     }
 }

[metalcoyote]

Merci!

Je vais tester tout ca

[metalcoyote]

Re,

J'ai un petit probleme avec le singleton.
Mon appli etant , mon appli etant multithread, plusieurs threads acceedent a des methodes ou des elements (listes) de cette classe singleton, et parfois j'ai ceci:

Code :

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

1
2
3
4
5
java.util.ConcurrentModificationException
        at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
        at java.util.AbstractList$Itr.next(Unknown Source)
        at monitor.ping.PingSenderThread.run(PingSenderThread.java:51)
        at java.lang.Thread.run(Unknown Source)

Ca appartait qund je parcours des listes de cette classe via un iterator.
Comment y remedier.

[jhaythem]

synchronized

[metalcoyote]

oui je sais bien mais on m'a dit de plutot utiliser les classes singleton.
comment faire ?

faut ke je mette toutes mes methodes/attributs de cette classe en synchronized ?

[jhaythem]

oui je sais bien mais on m'a dit de plutot utiliser les classes singleton.
comment faire ?

faut ke je mette toutes mes methodes/attributs de cette classe en synchronized ?

non juste tes methods on ne synchronize pas les attributs!

[metalcoyote]

ouip c vrai
Bon ca pete quand meme...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
ArrayList<MonitorBean> monitorsList_ = MonitorActions.getInstance().getConfig().getMonitorList();
Iterator<MonitorBean> it_ = monitorsList_.iterator();
 
ArrayList<MonitorBean> monitorsList_ = MonitorActions.getInstance().getConfig().getMonitorList(); 
		  Iterator<MonitorBean> it_ = monitorsList_.iterator();					
 
for (Iterator<MonitorBean> iterator = it_; iterator.hasNext();) {
	MonitorBean monitor = (MonitorBean) iterator.next();  <-- ICI
...
}

Pourtant ya "synchronized" sur la methode getMonitorList()

[mavina]

Salut,

La methode est synchronisée, la liste ne l'est pas.

Plusieurs solutions :

• sychroniser la liste :
  

  Code :

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

  List monitorsList_=Collections.synchronizedList(MonitorActions.getInstance().getConfig().getMonitorList());

• synchroniser le temps de l'itération :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
   
  sychronized(monitorsList_)
  {
  		  Iterator<MonitorBean> it_ = monitorsList_.iterator();
   
  		  ArrayList<MonitorBean> monitorsList_ = MonitorActions.getInstance().getConfig().getMonitorList(); 
  		   Iterator<MonitorBean> it_ = monitorsList_.iterator();					
   
  		  for (Iterator<MonitorBean> iterator = it_; iterator.hasNext();) 
  		  {
  			  MonitorBean monitor = (MonitorBean) iterator.next();  <-- ICI
  		  }
  ...
  }

Dans tous les cas, si tu as un probleme d'acces concurent, synchroniser uniquement les méthodes ne fonctionnera pas, puisque tu travailles sur les objets renvoyés par ces méthodes.

edit:vas faire un tour ici pour des infos sur la synchronisation des collections.

Cordialement

Fred

[jhaythem]

synchronize tes liste aussi

Code :

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

1
2
 
Collections.synchronizedList(List<T> list)

[Pollux]

Il faut que acquiers le verrou sur ta liste avant de récupérer l'iterator pour pouvoir la parcourir sans souci.

Code :

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

1
2
3
4
5
6
7
synchronized(list)
{
    for(Iterator it=list.iterator(); it.next();)
    {
         //traitement
    }
}

[metalcoyote]

Merci beaucoup !

Je vais voir tout ca

[adiGuba]

Salut,


Il pourrait également être intéressant de se pencher sur les ReadWriteLock de Java 5.0 et gérer toute la synchronisation à la main...

Cela permettrait d'éviter des blocages lorsque tous les threads accède à la liste seulement en lecture...

a++

[metalcoyote]

je note je note

[Pollux]

La classe CopyOnWriteArray peut aussi etre une piste