Reprise du message précédent :
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.

ok
 
pour le "maladroit", c'était une boutade, of course

Je m'en doutais un peu  

bon bah je vais opter pour le process externe et faire une appli java de base lancée en demon...
 
merci a tous.

MBean schedulé bordayl (oui je sais -- l'a déjà dit)
 
C'est quoi l'application server derrière?

 
en fait dans JMX, il existe un service de Timer standard donc portable.
 
sinon, j ai appris today qu il est autorise de manipuler des Thread dans le servlet container (c est dans l EJB layer que l on a pas  le droit)
 
le meilleur endroit pour creer/detruire des objets relatifs a une appli web c est d utiliser un ServletContextListener

Heu mais sinon j'ai une autre question : quand meme pour réaliser mon dump de la base (oublions la problématique de Timer pour l'instant), je pense à utiliser un "SELECT * INTO OUTFILE ma_table.sql ... export options ... FROM ma_table".
 
Cela permet en fait de dumper les données de la table ma_table dans un fichier texte, le truc après c'est que pour réobtenir un fichier d'ordres SQL réexploitable il faut se demerder avec les options d'export pour rajouter les textes necessaires (par exemples les mots clés INSERT INTO, mais aussi les mises entre quotes, les champs DEFAULT et tout ca).
 
Est ce une bonne idée de procéder ainsi ? Y a il plus simple  sachant que je veux faire cette opération en java uniquement (donc pas d'appel au binaire mysqldump, ca serait trop facile )
 
D'autre part il semble que le fichier spécifié après OUTFILE  est obligatoirement placé dans le répertoire base de données de MySQL (chez moi /var/mysql/PROJ/ car PROJ est la base de données que j'utilise). Y a il un moyen de pouvoir sauver ce fichier autre part ? Par exemple sur le poste client de celui qui execute l'application et non pas sur le serveur MySQL... qui en plus peut être différent du Tomcat hébergeant l'application bref pas pratique s'il est là bas pour réimporter en plus c'est le merdier.
 
Bon ca fait beaucoup de demandes mais je vous remercie par avance si vous avez des réponses à m'apporter

En fait je viens de réaliser l'existence d'un sous forum dédié au SQL donc je vais peut etre aller y faire un tour aussi...

pourquoi tu utilises pas la commande mysqldump tout simplement pour faire tes backups?

bah tout simplement pcq je veux le faire en java , c'est une contrainte de mon projet.
 
mais en fait après avoir lu la doc sur le site de MySQL je crois avoir trouver la solution à mes deux petits pbs concernant le dumping :
 
Pour ceux que ca interesse : il semble que LOAD DATA FROM FILE et SELECT INTO OUTFILE soient de format compatible par defaut, ce qui veut dire pas besoin de décorer la sortie du SELECT avec des INSERT et des quotes, puisque le LOAD va comprendre que c'est des INSERT de ligne et les faire (apparemment c'est meme "the truc" fait pour insérer une grande quantité de lignes)
 
Et ensuite pour le fichier y a une clause LOCAL dans la requête qui permet d'utiliser un fichier sur le client.
 
Donc ça devrait rouler

 
Ce genre de spécifications doit figurer en bonne place parmi les causes d'échec d'un projet. Faudrait documenter ça.

Oui, je l'ai effectivement dit sur ce thread ce même jour à 17h50.  

 
Oui je suis d'accord mais là il s'agit d'un projet pédagogique d'application d'un cours.
 
Mais sinon c'est clair qu'en vrai ca aurait été mysqldump + cron, vite torché quoi !

Bon bah en fait y a un truc que je capte pas pour le "LOAD DATA LOCAL INFILE 'file.sql' INTO TABLE toto" :
 
Lorsque j'utilise la directive LOCAL, ca ne marche pas rien a faire le MySQLd me pète une erreur Unable to open file!
 
Lorsque je vire cette directive, je met file.sql dans le repertoire de la base de données de mon proj (sur le serveur MySQL) et là ca fait bien le load dans la table toto.
 
D'ou ma question : a quoi sert LOCAL si ce n'est pas pour uploader d'abord un fichier sql du client vers le serveur.
 
De plus si je me reporte à la doc, on y trouve ce passage :
 
Si le mot clé LOCAL est spécifié, il est interprété en suivant les règles suivantes :
 
    * Si LOCAL est spécifié, le fichier est lu par le programme client, et envoyé vers l'hôte.
    * Si LOCAL n'est pas spécifiée, le fichier doit être sur le serveur hôte, et sera lu directement par le serveur.  
 
LOCAL est disponible depuis MySQL 3.22.6 ou plus récent.  
 
Depuis MySQL 3.23.49 et MySQL 4.0.2 (4.0.13 sur Windows), LOCAL fonctionne uniquement si votre serveur et votre client ont été configuré pour. Par exemple, si mysqld a été lancé avec --local-infile=0, LOCAL ne fonctionnera pas. See section 5.3.4 Problèmes de sécurité avec LOAD DATA LOCAL.
 
Et j'ai pourtant une version suffisamment récente
 
=> mysqld --version
mysqld  Ver 4.0.18 for unknown-openbsd3.5 on i386 (OpenBSD port: mysql-server-4.0.18)
 
Help

Yes ! Je crois que j'ai trouvé l'origine du problème ! (Merci les commentaires des utilisateurs sur le site MySQL !)
 
Donc pour info : http://dev.mysql.com/doc/mysql/fr/LOAD_DATA_LOCAL.html
 
Je cite :
 
Vous pouvez désactiver toutes les commandes LOAD DATA LOCAL du serveur MySQL en démarrant mysqld avec --local-infile=0. Similairement, pour mysqlimport, les options --local et -L active le chargement distant de fichiers. Dans ce cas, il faut que le serveur accepte aussi cette configuration pour que l'opération fonctionne.
 
J'ai donc shutdown le serveur sql, et redémarré avec local-infile    = 1 dans le fichier de conf
 
et ca marche ! ca envoie mon fichier que j'ai en local et ca le traite sur le serveur.

En fait j'ai encore un dernier petit pb pr l'envoi d'un fichier a loader par la suite : lorsque je recuperer la String indiquant quel est le fichier sur le client de l'utilisateur, je n'ai que le fichier sans son chemin (exemple si l'utilisateur selectionne c:\toto.sql dans la boite de dialogue parcourir du formulaire, request.getParameter("_sql_file" ) me renvoie juste "toto.sql" ).
 
Du coup cela me fait un File not found dans MySQL... Mais le code marche (si je met en dur "c:\toto.sql" ca load).
 
Comment accéder au nom complet du fichier ?
 
D'autre part après quelques recherches je suis tombé sur ca : http://jakarta.apache.org/commons/ [...] index.html
 
Est ce que ca vaut le coup de l'utiliser ? Est-ce nécessaire dans mon cas précis ???...

oh desole, j ai du mal lire
 

Y'a pas de mal, j'en remettais juste une petite couche pour moi-même. Quel loser pathétique je fais.

 
en fait ma perception est que cela etait interdit et c est pour ca que j ai ete surpris en apprenant ca.
 
ca empeche que pas mal d applis font n importe quoi, par exemple JSPWiki lance des thread sans garder les references, cad que qd l appli est redeployee ca recree des nouveaux threads et les anciens continuent a tourner en live dans la VM.

personne pour mon probleme de chemin complet ?

j'ai pas tout lu du topic ...
 
 mais je comprends pas bien ta question. Tu parles de chemins sur le post client, puis de loader le fichier sur le serveur ... tu mélangerais pas les deux ?
 
et quand tu upload un fichier, c'est pas que le nom d fichier que tu envoies, c'est totu le fichier. Ce fichier doit être créé et stocké sur serveur => à toit de le stocker quelque part et de mettre le bon chemin dans ta base.

sinon, pour file upload d'apache, ouais, tu peux utiliser ca pour sauvegarder le fichier uploadé côté serveur...

merci de ta réponse benou mais en fait le pb c'est que je ne peux recuperer que le chemin du fichier et non pas le fichier lui meme, et ce chemin est amputé du repertoire, il n'y a que le fichier en lui meme ("toto.txt" au lieu de "c:\toto.txt" par exemple). du coup le load n'est pas possible

tu fais comment pour récupérer ce chemin ? c'est un <input type="file"> nan ? ben ca ca upload le fichier. qu'est ce qui te fais dire que tu ne peux récupérer que le chemin ?