en fait j'aurais aimé avoir quelques informations concretes concernant le fonctionnement des Threads() avec une JSP et une Servlet.
 
mon probleme est que, je voudrais lancer une Servlet qui me declenche des requetes SQL via JDBC et cela prend beaucoup de temps parfois (environ 20 a 30 minutes, car je lance beaucoup de requete les unes a la suite des autres). Et en fait pour faire patienter l'utilisateur, je voudrais lui afficher une barre de progression en JSP avec des infos d'etats d'avancement.
 
mon souci c'est que je n'arrive pas a synchroniser l'ensemble, donc si quelqu'un disposait d'un exemple similaire concret, je l'en remercierais beaucoup
 
@+
TJ

Par curiosite, qu'entends-tu par "je n'arrive pas a synchroniser l'ensemble".
 
La solution qui me vient a l'esprit ne serait pas base sur une JSP, mais plutot sur une applet qui fait des requetes HTTP regulierement pour voir ou en est le traitement.
Mais bon avec un auto-refresh sur une jsp ca peut marcher aussi.
 
Le probleme, c'est que faire des requetes regulierement pour obtenir l'etat du traitement ("mode pull" ), ca te gener un trafic reseau non negligeable.
 
L'ideal serait de faire du "push" en utilisant  l API java Message Queuing (JMS) et une applet ...
 
Si j'ai le temps je posterai un exemple en "mode pull"

Tiens, je trouvais que c'etait interessant a essayer de programmer et  
voici ce que j'ai ecrit:
 
http://ajsanglard.com/photos_fab/j [...] essBar.war
 
Explication du code:
 
*Transaction est un thread:
Il fait le boulot, c'est par exemple l'object qui contient tes appels  
SQL. Il a un etat(int) qui progresse en fonction du pourcentage de la  
tache accompli.
 
*Monitor est un singleton qui regroupe toutes les transactions en  
cours.
 
*MonitorThreadCleaner est un thread qui toutes les heures nettoie le  
monitor des transactions expirees.
 
*DataBaseProcessor est une servlet qui recoit les demandes de  
traitement, cree une transaction avec un numero id unique et l'ajoute au  
Monitor, puis forward vers l'applet.
 
*TransactionMonitorer permet de consulter l'etat d'une transaction. En  
fonction de l'id passe en parametre, elle retourne l'etat de la  
transaction correspondante.
 
*Enfin "applet" est une applet qui toutes les 2 secondes envoie une  
requete HTTP vers TransactionMonitorer
pour connaitre l'etat de la transaction qu'elle surveille.
 
Pour consulter tout cela, place le war dans le repertoire WEB-INF de  
tomcat, et ouvre un browser a l'adresse suivante:  
http://localhost:8080/demoProgressBar/start.jsp
 

bartleby>
 
mais pourquoi est ce que tu n'est pas plutot passé par une interface Runnable pour représenter la transaction à effectuer ?
De plus en wrappant cette Runnable dans une autre , tu pourrais éviter devoir faire un thread de nettaoyage des transactions. ex :  
 

(pour faire rapide)
 
 
 
sinon, ce problème peut être traité via AJAX pour éviter l'applet.
un lien vers une explication de ce qu'est AJAX :  
http://java.sun.com/developer/tech [...] /?feed=JSC
et un lien vers un article sur une progress bar en ajax :
https://bpcatalog.dev.java.net/nona [...] rames.html

Salut benou
 
J'etend Thread dans mon exemple par (sale) habitude, j'avais appris ca en fac et j'oublie a chaque fois d'utiliser Runnable. Implementer Runnable serait bien plus propre en effet.
 
Malin le coup du double wrappage !! c'est un design pattern celebre ?
 
Merci pour le lien AJAX, c'est tres interessant.

beh, tant qu'à faire, autant présenter ton LongRunningUnitOfWork dans une interface spécialisée, plutot que d'exposer un Runnable qu'a rien à voir avec la choucroute non?
(dans le fond, on s'en bat les couilles que ça va etre executé dans un thread ou pas)
 
et sinon, pour éviter de tout refaire vous même, y'a surement des trucs interessants dans quartz? (meme si c'est plutot basé sur du scheduling)

j'ai pas regardé ses sources...
 
et oui, c'est surement une bonne idée de faire une interface plus spécialisée que Runnable. Runnable c'est déjà une première étape par rapport à un thread en dur
 
Faudrait une interface qu'on peut démarrer (run) et dont on peut demander l'état d'avancement, et éventuellement d'autres choses (état d'erreur, etc.)

"dans le fond, on s'en bat les couilles que ça va etre executé dans un thread ou pas"
 
Au contraire, le thread me semble indispensable.

tu n'as pas compris mon propos

Et quand je lis une reponse pareil,  ca ne m'interesse pas de le comprendre..
Nous n'avons rien a nous dire.

ok

Oula on se calme les amis!
 
Je pense également qu'une solution de type Scheduling voire workflow leger serait plus "J2EE style" (avec une étape pour chacune des groupes de requetes : comme ca il suffit de voir a quelle étape du workflow on est pour avoir l'avancement). Mais je le pense aussi parce que j'ai peu d'exp avec la manip directe de threads en Java. Maintenant ce type de solution est peu être un peu trop "bazooka pour tuer la mouche" ici sauf si l'application que tu developpes a plein de problématiques de ce genre
 
Par contre ce qui est sur c'est qu'il manque des JSP dans ton War non ? (applet.jsp notamment)  

ce que le monsieur veut te dire c'est que ton UnitOfWork n'a que faire d'etre execute dans un thread a part, ce n'est pas de sa responsabilite, sa responsabilite, c'est la logique d'execution. Le thread n'est qu'un contexte d'execution, et gerer ce contexte d'execution c'est plutot du ressort d'un autre objet qui se chargera d'executer tes UnitOfWork (genre un UnitOfWorkProcessor). l'utilisation de thread n'est pas remise en cause ici hein
 
enfin je crois

merci souk, j'avais juste pas le temps ni l'énergie pour expliquer ça; il l'a mal pris, mais j'ai d'autres chats à fouetter. notamment la rédaction d'un cv

j'imagine la lettre de motivation -- style :
 

m'enfin, ce hs

 
Oups, voila c'est repare !