Discussion :

[xss.xas]

Bonjour,

Dans le cadre d'une application web J2EE, j'ai crée un filtre qui ouvre et ferme une connection à la base de données. Cette connection est mise à disposition à chaque servlet via un request.setAttribute("connection", monObjetConnection);

Je n'ai qu'à faire ce qui suit dans ma servlet, le reste étant géré par le filtre :

Code :

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

 Connection con = (Connection) request.getAttribute("connection");

Ceci est-il une pratique raisonnable ou pas ? Mon intégrateur a un peu grincé des dents en voyant un DB2ConnectionFilter dans mon web.xml, et m'a demandé une petite justification. Comment gérez-vous vos connections aux bases de données ? (je n'utilise pas d'EJB, j'ai juste des servlets et des JSP, avec une classe comportant des méthodes statiques pour les fonctions métier).

Si j'ai raté un topic sur le sujet, je serais également ravi de le lire

[Pollux]

Les filtres n'ont pas pour objectif de fournir une connection à la base de données généralement.

Plus simplement ce sont tes objets métiers qui accèdent à tes données et qui donc crée une connection. Après tu peux faire un pool de connection sur une classe singleton ou statique si tu veux avoir plusieurs connections.

[elitost]

Cherche un peu du côté des DataSource qui te permettront d'obtenir un connexion pêchée dans un pool.

Regarde également l'API DBUtils de chez Apache , c'est assez puissant.

Un tuto sur le sujet :
http://christophej.developpez.com/tutoriel/api/dbutils/

[xss.xas]

Hmm je me suis mal exprimé manifestement, toutes mes excuses

En vérité, mon serveur d'application (websphere) me fournit déjà un pool de connections. J'utilise seulement le filtre pour en puiser une dans le pool ( Connection con = datasource.getConnection(); ) et mettre l'objet dans la ServletRequest ( request.setAttribute("connection", con); ).

Du coup, le filtre se charge de récupérer une connection ouverte, et libère la ressource automatiquement après l'exécution de la servlet. Je trouvais ça pratique, mais mon intégrateur semble surpris (et pas tellement en bien) par ma méthode.

Voyez plutôt :

Code java :

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
33
34
35
36
37
38
39
40
41
42
43
44
public class DB2ConnectionFilter implements Filter {
 
	FilterConfig config = null;
 
	private static String infoConnection = "";
 
	public void init(FilterConfig config) throws ServletException {
		System.out.println(config.getFilterName() + " initialisé");
		this.config = config;
	}
 
	public void destroy() {
		System.out.println(config.getFilterName() + " détruit");
		this.config = null;
	}
 
	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
		Connection con = null;
 
		try {
 
			DataSource ds = DbCfg.getDataSource(); // DbCfg effectue un lookup au chargement de l'application, et garde une référence sur la DataSource.
			con = ds.getConnection();
 
			request.setAttribute("connection", con);
////////////////////////////////////////////////////////////////// ALLER
			chain.doFilter(request, response);
////////////////////////////////////////////////////////////////// RETOUR
			request.removeAttribute("connection");
		} catch (SQLException sqlex) {
			sqlex.printStackTrace();
			throw new ServletException("La connection à la base de données n'a pas pu être établie pour la raison suivante : " + sqlex.getMessage());
		} catch (ServletException servEx) {
			servEx.printStackTrace();
		} catch (Exception e) {
			e.printStackTrace();
			throw new ServletException("Une erreur s'est produite dans DB2ConnectionFilter : " + e.getMessage());			
		}
		finally {
			try { con.close(); } catch (Exception e) { e.printStackTrace(); }
		}
	}
 
}

[djo.mos]

A quoi bon ? Le traitement que t'as fait dans ton filtre peut très bien être mis directement dans la Servlet ou mieux encore dans la couche métier (DAO) et t'évites ainsi le passage par le request.

Justement, tu l'as dit toi même, tu n'utilises pas EJB ni Hibernate ! Dans le cas contraire, oui, un filtre serait le bienvenu pour ouvrir une session de persistance (pas une connexion) et la fermer après le rendu de la réponse !

[azerr]

Bonjour

Je n'aime pas trop l'utilisation d'un filtre pour gerer les connections.
Dans ton code tu ouvre et ferme une connection a chaque fois, meme si tu n'en a pas besoin.

Moi je prefere separer en couche Service/DAO.Le post http://developpez.net/forums/showpos...83&postcount=4 parle de la gestion de la session Hibernate, mais pour une connexion JDBC, le probleme est le meme.

Je te conseille de stocker une connection dans une ThreadLocal au lieu de la stocker dans la request (dans le post que je t'ai donne j'ai explique l'interet de la ThreadLocal).

Angelo

[grishka]

Si ton but est vraiement de réutiliser la connexion jdbc durant tout le traitement de ta requête, tu devrais effectivement utiliser le pattern ThreadLocal (en gros une classe singleton avec une variable de type ThreadLocal contenant la connexion). Tu pourrais ainsi la récupérer n'importe où (et pas seulement dans une servlet).
Cela dit l'utilisation du filtre n'est pas trop déconnante : ca rejoins le principe du pattern "session per request" d'Hibernate. L'inconvénient est que tu risque de monopoliser une connexion jdbc trop longtemps, et du coup mettre en attente les autres utilisateurs...conclusion : c'est un pattern intéressant mais faut être sur 1) de pas avoir de traitement trop long ou 2) de pas avoir trop d'utilisateur