Donnees communes a plusieurs Serveurs

Version imprimable

31/10/2007, 11h29
metalcoyote

Donnees communes a plusieurs Serveurs

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 ?
31/10/2007, 13h33
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.
31/10/2007, 13h37
metalcoyote

OK merci du tuyau ! ;)

edit: Il n'y aura pas de prob de synchronisation avec RMI ?
31/10/2007, 13h57
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.
31/10/2007, 14h00
metalcoyote

Citation:

Envoyé par deltree

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 :ange:

Code:

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;
     }
 }

31/10/2007, 14h25
metalcoyote

Merci!

Je vais tester tout ca ;) :D

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:

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.

14/11/2007, 15h37
jhaythem

synchronized
14/11/2007, 15h41
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 ?
14/11/2007, 15h42
jhaythem

Citation:

Envoyé par 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 ?

non juste tes methods on ne synchronize pas les attributs!

ouip c vrai :roll:
Bon ca pete quand meme...

Code:

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()

Salut,

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

Plusieurs solutions :
sychroniser la liste :

Code:

List monitorsList_=Collections.synchronizedList(MonitorActions.getInstance().getConfig().getMonitorList());
synchroniser le temps de l'itération :
Code:

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

14/11/2007, 16h09
jhaythem
synchronize tes liste aussi
Code:

1 2 Collections.synchronizedList(List<T> list)
14/11/2007, 16h16
Pollux
Il faut que acquiers le verrou sur ta liste avant de récupérer l'iterator pour pouvoir la parcourir sans souci.
Code:

1 2 3 4 5 6 7 synchronized(list) { for(Iterator it=list.iterator(); it.next();) { //traitement } }
14/11/2007, 16h17
metalcoyote

Merci beaucoup !

Je vais voir tout ca
14/11/2007, 16h26
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++
14/11/2007, 16h38
metalcoyote

je note je note :hola:
14/11/2007, 23h37
Pollux

La classe CopyOnWriteArray peut aussi etre une piste