Discussion :

[Alec6]

J'ai une application Hibernate - Richfaces dans l aquelle on a un singleton
qui regroupe toutes les actions (CRUD notamment).

Donc à chaque fois que le client émet une request la GUI, plutôt que d instancier une classe de type action (comme dans le design pattern), récupère le singleton et appel une méthode.

Je soupçonne un impact sur les performances, et vous ?

[olivier.pitton]

Plop,

Pas forcément. Le problème viendrait plutôt de la concurrence. Si tu utilises plusieurs threads et que ceux-ci effectuent des opérations idempotentes (qui ne modifie pas l'état de l'objet, de ton singleton donc), alors tu n'as pas de soucis à te faire. Plusieurs threads peuvent effectuer un même traitement sur une même classe puisque leurs piles d'appels sont différentes (donc l'enregistrement de la fonction et l'empilement de ses variables locales se fait dans des endroits différents en mémoire).

En revanche, si plusieurs threads modifient l'état du singleton (qui contient des variables d'instance modifiables par exemple), alors oui tu as un problème, mais pas de performances.

Pour ce qui est des purs performances, théoriquement c'est plus performant d'avoir un singleton. Cela t'évites de créer des objets à courte durée de vie en mémoire, et donc te force à faire moins d'appels du GC.

[Alec6]

Oui mais comment J2EE fait sa vie par rapport a la serialisation - deserialisation des objets pour liberer de la memoire. Si le container veut de la memoire, en serialisant un objet qui garde un lien vers le singleton tandis qu un autre objet travail dessus est ce que ca peut pas poser un probleme. Car le singleton doit pas etre serialise lui.

Est ce que tu penses pas que ca peut poser un probleme ?

[olivier.pitton]

Quand tu me parles de singleton, tu parles d'EJB Singleton ? Si oui, rassure toi, le conteneur sait ce qu'il fait. Mais il faut littéralement manger de la mémoire pour en arriver à faire du swap.

A la base, ce sont les EJB statefull qui sont mis sur disque, afin d'éviter de tenir des contextes en mémoire qui sont potentiellement inutile, ou inutilisés depuis un certain temps. Les EJB Singleton ne sont pas mis sur disque. Sache néanmoins que par défaut, plusieurs threads ne peuvent au même moment accéder à ton EJB. Pour rendre cela possible, il faut utiliser

Code :

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

@ConcurrencyManagement(ConcurrencyManagementType.BEAN)

.

Selon moi, le problème réel derrière n'est pas les performances, mais la concurrence. Si tu autorises plusieurs threads à accéder au même moment à ton singleton, faudra gérer à la main le verrouillage. Sinon, tes threads sont mis en attente pendant que l'on utilise ton EJB.

[Alec6]

En faite j ai des singletons de classes classiques (pas EJB), et effectivement j'ai des méthodes en synchronized.

Merci pour ta réponse ça m’éclaircit les idées