Ok merci pour la r�ponse.
> D'une mani�re g�n�rale, dans un environnement J2EE, il est
> pr�f�rable que seul le serveur d'applications (dont le role
> principal est de g�rer la bonne utilisation des ressources
> syst�me) effectue des appels au GC dans des circonstances
> tr�s particuli�res et rares.
Cel� r�pond le mieux � ma question.
En fait, je posais des questions relatives au jdbc.
Dans la m�thode close() de l'interface Connection, il est pr�cis� ceci :
A Connection object is automatically closed when it is garbage collected.
Certain fatal errors also close a Connection object.
Dans l'appli, il peut se produire certaines exceptions dans certains objets
qui ne ferment pas les connexions.
Donc je voulais m'assurer qu'un appel au gc me lib�re effectivement les
connexions.
Olivier

----- Original Message -----
From: "Alexis Moussine-Pouchkine - Sun France - Computer Systems - ITC"
<[EMAIL PROTECTED]>
To: "Olivier LAMY" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, July 17, 2002 1:52 PM
Subject: Re: Utilisation de System.gc();


> Les quelques rares situations qui justifient un appel �
> System.gc() sont celles ou, du fait de la taille importante
> de la heap (plusieurs centaines de Mo) et des 'freeze' de
> l'appli que cela engendre, il est important de s'assurer
> qu'une phase critique de l'application ne sera pas
> compromise du fait d'une m�moire trop fragment�e ou
> d'une pause trop longue de GC. Ceci dit, il n'est pas
> possible de garantir qu'un GC ne se d�clenchera pas
> pendant une p�riode donn�e. Aucun d�terminisme sur les
> activit�s d'un GC n'est possible.
>
> Par contre, il peut etre utile de faire un minimum de tuning
> sur la JVM: taille de heap de d�but et max, taille des
> g�n�rations, etc...
> Ces recommandations sur ces options varient selon les JVM,
> leurs versions et les OS. Pour les JVM HotSpot:
> http://java.sun.com/docs/hotspot/gc/index.html
>
> En tout cas, la premi�re �tape consiste � effectuer des
> runs avec un -Xverbose:gc pour se rendre compte du temps
> maximum et total pass� par l'application en GC.
>
> D'une mani�re g�n�rale, dans un environnement J2EE, il est
> pr�f�rable que seul le serveur d'applications (dont le role
> principal est de g�rer la bonne utilisation des ressources
> syst�me) effectue des appels au GC dans des circonstances
> tr�s particuli�res et rares.
>
> Les appels p�riodiques au GC, qui pouvaient etre recommand�s
> il y a qq temps avec certaines JVM ne sont plus d'actualit�.
> Par contre, positionner des variables � 'null' reste un
> utile.
>
> L'appel des finaliseurs est une fonction de l'algorithme
> du GC, donc assez peu portable et peu pr�dictible. La
> m�thode runFinalization() augmente les chances d'ex�cution
> des finaliseurs, mais ne peut le garantir.
> Pourquoi utilises-tu des finaliseurs?
>
> Cdlt,
> Alexis
>
> Olivier LAMY wrote:
> > Bonjour,
> > Dans un but d'optimisation, je me pose des questions quant � l'utilit�
de
> > System.gc(); ?
> > Mon cas, une servlet re�oit des messages SOAP. Celle-ci cr�� un objet de
> > traitement et renvoie une r�ponse. Cet objet de traitement cr�� de
multiples
> > beans (avec des acc�s SGBD).
> > Je me demandais donc si apr�s mes diff�rents traitements et avant le
return
> > de ma servlet, l'utilisation de System.gc(); �tait appropri�e ou
totalement
> > inutile ?
> > Ou alors faut-il utiliser runFinalization() qui n'est pas lanc� en t�che
de
> > fond mais attend la fin avant de continuer ?
> > Mon application tourne sous jaguar CTS3.6.1  (jdk 1.3 je crois).
> >
> > Olivier
>

Répondre à