Utiliser un ou plusieurs servlet ?

Bonjour,

Je développe actuellement une application Web.

Celle-ci est basé autour de plusieurs actions nécessitant chacune une connexion à une base de données.

J'utilise actuellement le package URL Rewriter afin de faire de ... l'URL Rewriting (on s'en serait douté ;) ).

Est-il plus intéressant de :

1) Faire pointer toutes mes requetes sur un seul servlet qui va appeler les bonnes actions en fonction d'un paramètre et n'utiliser qu'une seule connexion à la base de données (avec des synchronised pour les problèmes d'appels concurrents)

OU

2) Mettre en place un servlet par action (les faire implémenter single ThreadModel pour éviter les problèmes d'appels concurrents) étant donné que la redirection sera mise en place au niveau de l'url rewriting?


Merci de vos réponses, j'ai du mal à cerner les inconvénients et avantages à n'utiliser une seule ou plusieurs servlet...

Hello,

Je ne suis pas sûr d'avoir une réponse complète à te fournir, mais je dirais que la réponse doit venir de ta conception et des patterns que tu vas implémenter. Par exemple, si tu fais un MVC avec Struts, oublie la notion de servlets mais parle plutôt d'actions (comme tu le fais déjà). Et dans ce cas, ton boulot consiste à définir l'enchaînement des pages (dans struts-config.xml) et à écrire une classe par action. Après, si tu fais un MVC maison, tu peux partir sur un type d'implémentation identique à Struts (ce que j'ai dû faire à une époque lointaine) ou effectivement faire une action = un servlet.

Quant au JDBC, c'est à peu près pareil : fais d'abord la conception. De toute façon, si tu veux faire les choses proprement, il ne me semble pas correct de "persister" les connexions JDBC au niveau action. Généralement, on implémente une couche d'abstraction pour gérer les données et c'est cette couche d'abstraction qui "tient" les connexions à la base. Ensuite, pour obtenir des connexions à la base, on passe par le pool de connexion JDBC du serveur d'appli en faisant un lookup JNDI. C'est très pratique car cela évite, au niveau appli, d'avoir justement à gérer la problématique des connexions dispo/pas dispo, en échec, etc. Donc passe d'abord par là. Mais si tu tiens vraiment à n'avoir qu'une seule connexion à la base, par exemple parce que ton conteneur de servlet ne sait pas faire de pooling JDBC, sache qu'il est possible d'utiliser un singleton (hors servlet, donc) pour n'avoir qu'une seule instance de certains classes.

Quant au SingleThreadModel, je ne sais pas trop ce que tu veux faire : tu dis que c'est "pour éviter les problèmes d'appels concurrents", certes mais pour quelle raison exactement ? Le modèle des servlets fait justement en sorte que les servlets sont nativement multithreadés et généralement ça ne pose aucun problème. Passer par le SingleThreadModel ça revient à peu près à faire du synchronized sur les servlets. Il peut y avoir des cas où on a effectivement besoin de contrôler les accès concurrents, mais généralement on évite de la faire. Il est donc impératif de s'assurer que le mode "synchronized" est indispensable avant de se lancer : dire simplement "j'ai entendu dire que les accès concurrents, ça pouvait poser pb, alors je vais faire du SingleThreadModel" est sans doute la plus mauvaise raison de faire du SingleThreadModel ;) Il y a de vraies raisons techniques pour vouloir le faire, alors il faut les déterminer avant de se lancer là-dedans.

Bon courage.

Pour continuer sur la lancée de _Mac_, le SingleThreadModel est deprecated depuis la version 2.4 de l'api servlet... et effectivement, ce n'est pas une bonne idée de synchronizer une méthode doPost ou doGet ou service d'une servlet et tu pourrais même tout verrouiller.
Imagine ce cas avec méthode synchronize :
Servlet A appel -> Servlet B
Servlet B appel -> Servlet A

Un utilisateur 1 appel Servlet A quasi au même moment qu'un utilisateur 2 appel Servlet B.
Servlet A commence son traitement pour utilisateur 1,
Servlet B commence son traitement pour utilisateur 2,
Servlet A veut appeler Servlet B (mais B est verrouillée par utilisateur 2)
Servlet B veut appeler Servlet A (mais A est verrouillée par utilisateur 1)...
les 2 seront verrouillés et tu n'auras plus qu'un arrêt/relance du serveur pour régler le problème.

Pour ce qui est des actions struts, je pense pour ma part qu'il est préférable de créer une classe étendant DispatchAction et de gérer plusieurs "actions" liées entre elles par la nature de l'objet qu'elles gèrent.
Par exemple, tu vas avoir une action de lecture, une de mise à jour (au sens large) et une de suppression (que du classique). Elles partagent toutes le même formulaire en entrée. Il serait dommage de créer autant d'Actions alors qu'on peut les regrouper dans la même classe DispatchAction (ou LookupDispatchAction).
Si tu n'utilises pas struts (ou autre frameword MVC 2), tu peux faire la même chose avec des servlets, en utilisant un paramètre dans le request qui permettra de rooter.

Ton problème semble plutôt venir du code lié à la DB et là, il y a une multitude de possibilités, plus ou moins complexes :
- 1 classe avec méthodes static pour l'acquisition/libération de connexion
- 1 pool de connexion
- hibernate
- ejb
etc...


Bref, pour conclure, ni ta sollution 1, ni la 2 ne sont bonnes...
Il faut mettre en place un mécanisme compatible avec le multi-thread quitte à attendre la libération d'une Connection au niveau d'un pool (l'attente sera gérée par un objet spécifique d'acquisition)

A+

Rebonjour !

Merci de vos réponses.

Je vais me dépatouiller avec tout ca ;) !

Citation:

---

Envoyé par OButterlin

Bref, pour conclure, ni ta sollution 1, ni la 2 ne sont bonnes...

---

:) J'osais pas le dire !

Citation:

---

Envoyé par _Mac_

:) J'osais pas le dire !

---

Mais si, il faut être impitoyable :mrgreen: