Hello!
 
Je réalise actuellement une appli d'emploi du temps en J2EE avec servlets et jsp.
 
Une des fonctions de cette appli est la sauvegarde automatique des bases de données (utilisateurs, rendez-vous) toutes les x heures (par defaut toutes les 24 heures).
 
Je voudrais savoir comment faire pour lancer ma fonction toutes les x heures de façon automatique, je n'ai aucune idée de la manière dont procéder.
 
D'ailleurs, est-ce possible uniquement à l'aide de jsp / servlets ?
 
Si je suis pas clair demandez de reexpliquer

utilise java.util.Timer, c'est fait pour ça. (attention, ne confond pas avec javax.swing.Timer)

et bah voila merci je vais regarder de ce coté
 
tu gères El_gringo

euh ouais par contre faire ça "à l'aide de jsp / servlets" ça risque d'etre méchamment bancal...

tiens, comment on ferait ca proprement dans un environnement J2EE ?
 
y a moyen de balancer un evenement à un composant de façon périodique ?

en j2ee, tu peux utiliser des mbeans 'schedulés'.(une "operation" est appelée periodiquement)... je n'en sais pas bcp plus, je me demande si c'est pas propre à jboss en fait, mais je suppose que la plupart des serveurs offrent ce services.
mais en ejb-2.1 il semblerait qu'ils auraient ajouté un truc à ce sujet?? à confirmer?
 
sinon y'a des api comme quartz; je pense que lorill l'a déjà utilisé.

bah en fait je voudrais dumper une base sql (en gros faire un export de toutes les tables de la base uniquement les donnees sans la structure c'est a dire tous les INSERT qu'il faut)
 
et ce dumping devrait se faire automatiquement toutes les 24 heures et aller dans un fichier sql.
 
je vais continuer a regarder mais ca a pas l'air simple
 
de plus j'ai un autre pb plus petit celui la : je n'arrive pas a ecrire dans un fichier depuis ma servlet qui fait le dumping. si vous avez des idees...

Pourquoi Timer poserait problème dans un environnement de servlets au juste ?

peut etre parce que t'es pas supposer y créer de threads ?

utilise un process externe.

 
J'savais pas !
ça gêne en quoi de créer ses propres thread dans un environnement de servlets, si on les gère correctement ?

je vois pas comment tu pourrais les gérer correctement puisque tu n'as aucun controle sur les threads de tes servlets.
(à moins peut etre de jouer avec ça dans des ServletContextListener, et encore, tu serais obligé de garder une ref vers tes threads dans le context)

ben, on pourrait par exemple gérer des threads  "visiteurs" avec les "session listeners" ou des thread d'appli, avec les "context listeners", ...

 
en fait c'est dans le cadre d'un projet purement J2EE donc je peux pas utiliser un process externe sinon j'aurais fait ca c'est clair.
 
c'est pas grave je vais essayer de me démerder. au pire je ferais pas cette fonctionnalité.
 
merci pour ton aide.

si c'est un projet j2ee alors pourquoi tu ne vois que jsp/servlet ?

en fait quartz c'est un peu plus qu'une api, on peut déja l'utiliser tel quel.

oui je voulais dire librairie.(?)
tu as une idée de comment ça fonctionne en interne?

the real : pcq on a limité notre solution technique aux jsp / servlets pour ne pas s'embarquer dans des choses que nous ne maitrisions pas du tout (EJB...)
 
lorill : quartz ca pourrait marcher pour mon truc ?

oui ben donc vous faites du jsp/servlet pas du "pur j2ee"

j'ai pas trop regardé.
 
y'a une notion de triggers, et de jobs (en gros ils ont découplés le déclancheur du traitement), et de temps en temps quartz demande au trigger la date de prochaine execution, etc...

pas si tu ne veux pas de process externe

Qu'est-ce que du "pur J2EE" ? JSP/servlet est un subset parmis d'autres. Faut-il utiliser des entity beans pour faire du pur J2EE, ou des session beans suffisent-ils ? MD beans ? JMS ? etc.
 
Mais de là à dire que c'est une appli "J2EE", c'est un peu galvauder le terme.

 
Pourquoi un process externe est nécessaire ?  
 
une startup class qui initialise le Scheduler de quartz c'est pas suffisant ?

franchement, je ferais ca via un cron sur le serveur... je sais ca aide pas beaucoup comme reponse. mais faire ca via l'appli je trouve pas ca propre juste pour un backup

c ce que je voulais dire

oui mais c'est plus portable la

 
effectivement, j'avais pas pense a cet aspect

mouaif

 
Pkoi tu veux pas créer de thread dans une appli type servlet ? je vois pas le problème ...
Le moteur de servlet gère son pool de thread pour traiter les requêtes entrantes, mais je vois pas en quoi ca peut être gênant de créer ses propre threads ... Après bien sûr, faut les gérer correctement, mais le cycle de vie des servlets et autres ContextListener étant bien définis, ca pose pas de soucis ...
 
D ailleur, je me gêne pas pour en créer, moi, des threads ... et même des pool de threads ... d ailleur, je suis même en train de me dire que je vais me faire un petit timer dans un servlet, là

joli joce bug :  

doit y avoir moyen d'en faire des choses avec ca !  

 
C'est bon d'être soutenu !

En général, t'as plus vite fait de faire tourner ton job de backup en dehors de ton container J2EE.
 
Tu as rarement besoin d'accéder à de la business logic déjà en place, ni de réutiliser de composant J2EE pour ce faire.
 
La manie du "tout en J2EE" pour satisfaire un client ou pour assouvir un fantasme n'est souvent pas la manière la plus adaptée.
 
Faire du J2EE pour le plaisir de faire du J2EE, c'est plus que discutable - chacun faisant ce qu'il veut, en ce compris utiliser une fourchette pour boire sa soupe.
 
Un cron qui lance un script à la con ou tout autre variante, en ce compris en utilisant les facilités mises à disposition par ton DBMS, est plus efficace pour faire un backup que du code java, peu adapté et maladroit.
 
De quelle portabilité parle-t-on ici ? La plupart des DBMS fournisse une interface graphique dans laquelle il est possible de scheduler des jobs, en ce compris backup, de manière administrative plutôt que programmatique.

 
(cela dit, en faisant le backup, faut penser à ce que l'appli est en train de faire, donc on peut avoir besoin de - au pire - bloquer l'appli pendant un moment)

je vois pas en quoi le code java serait peu adapté et c'est pas gentil de supposer que notre ami ferait un code maladroit

c'est vrai, c'est tellement pratique de faire un backup a coup de jdbc

ouais, dans la cas d'un backup, ok ... je parlais plus d'un point de vue générale, là ...

personne parlait d'un point de vue general, on parle d'un "cron" pour faire un backup ici

kakakikikuku

Benou, je parlais bien in concreto de faire un backup, et pour avoir fait moi-même cette erreur un jour quand j'étais jeune et fou, je déconseille vivement de le faire en java.
 
Et tu as bien compris que je parlais de code maladroit non pas à cause de son auteur, mais parce que c'est inhérent à une telle tâche.
 
Pour ce qui est des threads, rien n'empêche effectivement d'en démarrer dans une appli J2EE. La limitation du multi-threading se situe au niveau des EJB, d'où peut-être la confusion de real.