Discussion :

[drKzs]

Bonjour,

je voulais avoir quelques précisions concernant les classes statiques: quelle est leur durée de vie ?

Je m'explique: je dois modifier une application java, qui communique avec une base de données. telle qu'elle était avant, pour des données géographiques, les données étaient entrées directement dans le code, dans une classe statique.
il suffisait d'appeler cette classe.

Geographic.getCountry("france") ;

Ne trouvant pas cela très joli, j'ai donc déplacé les données en base, mais pour leur appel, plutôt que d'appeler la base à chaque fois, vu que ce sont des données constantes, j'ai souhaité conserver l'utilisation d'une classe statique.

Donc ma classe a un attribut List, ou je liste tous les pays. Une méthode init() initialise la liste à partir de la base.

ensuite pour mes accesseurs, ça donne à peu près

public static Country getcountry() {
// pour le premier appel
if (myList==null)
init() ;
//traitement sur mylist et retour du pays
}

en regardant les traces, j'ai l'impressions que init() est appelée plusieurs fois, pas à chaque utilisation des accesseurs cependant.
Je pensais qu'elle ne serait appellée qu'une seule fois, au premier appel, car je pensais qu elecycle de dvie d'une classe statique correspondait à celui de l'application, et idem pour ses attributs...

Quelqu'un pourrait méclairer ?
Merci

[herve91]

Bonsoir,
je ne vois rien à redire à ton implémentation, elle est tout à fait correcte. Il faut être sûr que init() n'est appelée qu'une seule fois :

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
public static Country getCountry() {
  if (myList == null) {
    init() ;
  }
 
  ...
  return country;
}
 
private static List myList;
 
private static void init() {
  // au pire : if (myList == null) {
  myList = new ArrayList();
  ...
  // }
}

[drKzs]

merci pour ta réponse, ça appuie ce que je pensais mais dont je n'étais pas sûr... Vu qu'il s'agit d'une application déployée sur un serveur d'appli, le cycle de vie n'est peut être pas le même qu'une application java classique.

Je vais continuer à tracer l'appel à init, pour comprendre ce qu'il se passe.

Merci

[divxdede]

merci pour ta réponse, ça appuie ce que je pensais mais dont je n'étais pas sûr... Vu qu'il s'agit d'une application déployée sur un serveur d'appli, le cycle de vie n'est peut être pas le même qu'une application java classique.

Je vais continuer à tracer l'appel à init, pour comprendre ce qu'il se passe.

Merci

Sur un serveur d'application J2EE, chaque containeur a son propre classloader qui vont charger leur propre définition des classes.

[drKzs]

hmmm... et comment sont réparties les utilisations des containers ?

[divxdede]

hmmm... et comment sont réparties les utilisations des containers ?

Pour faire simple:

1x containeur par ejbjar "standalone"
1x containeur par ear (qui possédera donc plusieurs ejbjar gérés par le même containeur)

[thibaut]

Petite remarque, il ne faut pas synchronizer tout ça pour que plusieurs threads n'interviennent pas conjointement (il peut arriver que un thread soit en train de créer l'objet dans init(); pendant qu'un autre thread passe dans la cas du if et donc que le tet myList == null soit vrai aussi...

Code :

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

1
2
3
4
5
6
public static synchronized Country getcountry() {
  // pour le premier appel
  if (myList==null)
    init() ;
  //traitement sur mylist et retour du pays
}

[bulbo]

Petite remarque, il ne faut pas synchronizer tout ça pour que plusieurs threads n'interviennent pas conjointement (il peut arriver que un thread soit en train de créer l'objet dans init(); pendant qu'un autre thread passe dans la cas du if et donc que le tet myList == null soit vrai aussi...

Code :

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

1
2
3
4
5
6
public static synchronized Country getcountry() {
  // pour le premier appel
  if (myList==null)
    init() ;
  //traitement sur mylist et retour du pays
}

Juste pour chipoter, moi j'aurais juste synchronize la methode init, et deplacer le test (myList == null) au debut de cette methode.

Synchronizer getCountry et plus dommageable car cela veut dire que l'on ne peut pas faire un getUser par exemple en meme temps alors que seul l'init ne doit pas etre fait de maniere concurrente.

Bulbo

[thibaut]

Quel chieur celui-là ...