Afin de régler un problème constant lors de l'emploi de Begin and Close transaction, il semblerait que l'usage d'un filtre semble une bonne solution. Y aurait-il quelqu'un qui aurait un exemple tres simple de l'utilisation de d'appel du filtre.

J'ai trouvé le code suivant que je trouve très intéressant mais je ne sais pas comment l'appelé de l'objet DAO.

public class SessionFilter implements Filter
{
private FilterConfig filterConfig;

public void doFilter (ServletRequest request,
ServletResponse response,
FilterChain chain)
{
try {
chain.doFilter (request, response);
}
catch(Exception e) {
// handle!
}
finally {
HibernateUtil.closeSession();
}
}

public FilterConfig getFilterConfig()
{
return this.filterConfig;
}

public void setFilterConfig (FilterConfig filterConfig)
{
this.filterConfig = filterConfig;
}
}

Comment la methode test peut-elle accéder au filtre???

public class Dao {
// ...
public List search(String string) throwns Exception {
try {
HibernateUtil.beginTransaction();
Query query= HibernateUtil.getSession().getNamedQuery("test");
query.setString("string", string);
HibernateUtil.commitTransaction();
return query.list();
} catch (HibernateException ex) {
System.err.println(ex.getMessage());
} finally {
//HibernateUtil.commitTransaction();
HibernateUtil.closeSession();
}
}

Merci

Hibernate version:
Hibernate 2.1.6
Mapping documents:

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs:

Name and version of the database you are using:
Oracle 9
The generated SQL (show_sql=true):

Debug level Hibernate log excerpt:

Sauf très grosse erreur de ma part tu es sur la mauvaise voie.

Un filtre n'est pas appelé par ton code - il appelle indirectement ton code. Il est une sorte de parenthèse autour du code qui est exécuté dans le Servlet.

La code que tu montres est utile pour des applications bâties par example avec Struts qui utilisent Hibernate.

Erik

L'application que l'on bâti utilise Struts et Hibernate. Je viens également de me rendre compte que pour régler le problème que je viens de soulever, des sessions sont laissées ouvertes espérant que le prochain appel getSession fermera celle laissé ouverte. Je ne crois pas que ce soit là une bonne solution. Autre que le filtre que me suggères-tu?? Puis-je trouver quelque chose dans le livre Hibernate in Action qui m'aiderait???

Merci

Attention: je n'ai pas dit que Filter n'est pas utilisable, j'ai seulement dit

Dans le cas de ton application avec Struts et Hibernate c'est au contraire une bonne idée, mais il faut l'utiliser correctement et pour cela comprendre comment "marche" un Filter.

Je n'ai malheureusement rien trouvé sur les Filter dans Hibernate in action - par contre le lien suivant pourrait peut-être t'aider, si tu ne le connais pas déjà: http://www.hibernate.org/43.html

Erik

Je n'avais pas trouvé ce lien, merci. Je suis aussi d'accord avec toi sur le fait que je doives apprendre ce qu'est un filter, ce qu'il fait et comment il fonctionne. Je suis sure qu'avec le temps (meme restreint) je devrais trouver enfin j'espère.

Merci

Je ne suis pas sûr d'avoir tout bien compris. S'agit-il de factoriser le code de de début de transaction et celui de fin de transaction ?

Un petit schéma :

<servlet>
<composant métier>
<composant DAO1>
<début transaction/>
<une requête A hibernate dans une session/>
<fin transaction/>
</composant DAO1>
<composant DAO2>
<début transaction/>
<une requête B hibernate dans une session/>
<fin transaction/>
</composant DAO2>
</composant métier>
</servlet>

A chaque requête, on est obligé d'ouvrir une transaction puis de la fermer.
L'idée est de se ramener au schéma suivant :

<servlet>
<début transaction/>
<composant métier>
<composant DAO1>
<une requête A hibernate dans une session/>
</composant DAO1>
<composant DAO2>
<une requête B hibernate dans une session/>
</composant DAO2>
</composant métier>
<fin transaction/>
</servlet>

Ai-je bien compris la finalité ?
Dans ce cas, je me demande s'il est correcte de sortir la gestion des transactions de la couche DAO.
Si l'on évite de créer n connexions à la base (quoiqu'avec un pool, ce n'est pas pénalisant), qui correspondent aux n requêtes, on mélange les couches.
Et que faire quand la servlet n'utilise pas de requête ? Ne risque-t-on pas d'ouvrir et fermer une connexion pour rien ?

J'espère ne pas avoir dit trop de bêtises et obtenir vos remarques sur le sujet qui me semble intéressant.

Oui.


Oui


Je pense que sortir la gestion des transactions de la couche DAO n'est pas obligatoirement un problème.

On peut comparer un filtre à un aspect (dans le sens de la programmation orientée aspect). Et il est possible de d'examiner la requête dans le filtre et par conséquent de ne pas ouvrir systématiquement une transaction - mais cela commence à nous entraîner trop loin...

À tort ou à raison je considère qu'un filtre n'est pas vraiment une solution idéale - ta remarque sur le mélange des couches a du vrai. Avec un framework comme Spring il est possible d'être plus "subtil" et d'utiliser la puissance de la programmation orientée aspect sans mélanger les couches - mais je ne peux pas là non plus aller dans les détails. Si tu veux en savoir plus sur ce thème, lis par exemple http://static.springframework.org/spring/docs/1.2.x/reference/transaction.html).



Mes quelques remarques sur ces thèmes. Il est clair que le sujet n'est qu'égratigné superficiellement - il y a certainement des rangées entières de livres sur ces thèmes...

Erik

Notre application utilise Struts et Hibernate pas Spring. Nous n'avons pas non plus de connection Pool. Nous avons implémenté le filtre pour résoudre le problème queLazy connection nous posait. Le filtre fonctionne à merveille. Toutefois comme nous sommes nouveau dans le domaine de la programmation Java, nous ne pouvons nous prononcer plus à fond sur les effets que le filtre pourrait avoir au cours du développement de l'application.