Discussion :

[Zorgz]

Bonjour,

tout le monde sait qu'il faut faire un stmt.close() avec son resultset egalement.

Mais moi ds mon appli ma JTable prend ses donnees d'un ResultSet donc je peux pas le fermer ni son stmt egalement.

Etant donne que j'effectue plusieurs requetes frequement j'ai decide de creer et le stmt et son resultset statiques.

Alors la question est: faut il faire un resultset.close() juste apres avoir effectuer une nouvelle requete et avant de lui attribuer les nouvelles donnees?

Je me suis dit que puisqu'il est statique (le resultset) il ne consommera pas de nouvelles resources systemes mais en gardera ceux qui lui ont ete attribuer au moment de sa creation ai je raison ou je me trompe?

Parcequ'un resultset non fermer avec son stmt peux provoquer des fuites de memoires...et oui!!

[adiGuba]

Salut,

Etant donne que j'effectue plusieurs requetes frequement j'ai decide de creer et le stmt et son resultset statiques.

Pour commencer je dois dire que je ne trouve pas cela très propre de mettre un ResultSet en static...

Il devrait plutôt se retrouver dans le TableModel de ta JTable...

Alors la question est: faut il faire un resultset.close() juste apres avoir effectuer une nouvelle requete et avant de lui attribuer les nouvelles donnees?

OUI !

Je me suis dit que puisqu'il est statique (le resultset) il ne consommera pas de nouvelles resources systemes mais en gardera ceux qui lui ont ete attribuer au moment de sa creation ai je raison ou je me trompe?

Parcequ'un resultset non fermer avec son stmt peux provoquer des fuites de memoires...et oui!!

Tu confond deux choses :

• La mémoire utilisé par le ResultSet, qui comme pour tout les objets est géré par le GarbageCollector, et qui est donc géré automatiquement. Que les objets soient static ou pas tu n'as rien à faire pour cela.
• Les ressources autre que la mémoire, qui ne sont pas géré par le GC. Pour communiquer avec la Base de données il y a de fortes chances que le driver JDBC utilise des ressources spécifiques (généralement une socket, mais cela peut être n'importe quoi). Or si tu n'appelles pas la méthode close() ces ressources ne seront pas libérés...

De même, pour la base de données, le ResultSet serait toujours considéré comme ouvert, et la BD conservera surement des données en mémoire propre à ce ResultSet pour optimiser les futurs accès...


Bref : pour tout cela il est obligatoire de fermer proprement les ResultSet/Statement/Connection lorsqu'il ne sont plus utilisé.

Car en plus d'utiliser des ressources pour rien, tu pourrais atteindre des limites systèmes imposé, car un trop grand nombre de sockets ouvertes, ou trop de connection à la BD...


a++

PS : En général, si le driver JDBC est bien implémenté, il utilise la méthode finalize() comme garde-fou pour libérer les ressources, mais il vaut mieux ne pas trop s'y fier et libérer proprement les ressources...

[Zorgz]

Pour commencer je dois dire que je ne trouve pas cela très propre de mettre un ResultSet en static...

Il devrait plutôt se retrouver dans le TableModel de ta JTable...

Euh oui...mais qu'y a t'il de mauvais si mon TableModel puise ses donnees directement d'un ResultSet?

[adiGuba]

Euh oui...mais qu'y a t'il de mauvais si mon TableModel puise ses donnees directement d'un ResultSet?

Il n'y a rien de mauvais, mais tu n'as pas besoin de mettre le ResultSet en static, il suffit simplement de l'utiliser en tant qu'attribut d'instance.

Bien sûr il faut alors proposer une méthode close() qui permettra de libérer proprement les ressources, et de fermer chaque ResultSet avant de le remplacer par un autre, par exemple :

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
23
24
25
26
27
28
29
30
31
32
class TableModel extends AbstractTableModel {
 
	private ResultSet resultSet = null;
 
	public void close() throws SQLException {
		if (this.resultSet!=null) {
			this.resultSet.close();
			this.resultSet = null;
		}
	}
 
	public void setResultSet(ResultSet rs) throws SQLException {
		// On ferme le ResultSet précédent :
		close();
 
		// On affecte le nouveau ResultSet :
		this.resultSet = rs;
 
		// On lance les listeners associé :
		super.fireTableDataChanged();
	}
 
	// Garde fou : si l'objet n'est plus en mémoire
	// on libère le ResultSet qui lui est associé
	protected void finalize() throws Throwable {
		super.finalize();
		close();
	}
 
	// ...
 
}

Par contre ce qui peut être gênant, c'est que les accès aux données se font depuis l'EDT, ce qui peut ralentir l'affichage... mais c'est plus un problème de GUI de de JDBC...

a++

[Zorgz]

d'accord j'ai compris...merci.