Bonjour,
 
Je cherche à modifier un fichier texte de la forme :
 
*
param1 = valeur1
param2 = valeur2
...
*
 
Le but est de pouvoir modifier les valeurs des parametres et eventuellement en ajouter de nouveaux. De plus, je ne veux pas avoir à relire puis reécrire le fichier à chaque fois étant donné que celui-ci peut contenir plusieurs centaines (milliers) d'entrées de ce type...
 
Merci d'avance.

pk tu te fais pas une structure en XML deja par exemple, t'auras deja de meilleur outil pour travailler

Est-ce que cela fournit une solution performante ? (la structure XML est effectivement adaptée à mon programme, mais je n'était pas sur des performances si j'effectue beaucoup de modifications...)

J'my connais pas vraiment en java, mais en gros tu lis le fichier avec un parser, tu fais tes modifs en mémoire et puis tu réécris
 
ne pas réécrire complètement dans un fichier c'est pas nécessairement facile, et puis à moins que tu sois avec un vieux disque pourrave, ca devrait pas beaucoup influencer les performances (même avec quelques milliers de lignes)

Java est EXCESSIVEMENT performant en XML, à condition d'utiliser correctement les bons outils.
 
Sinon, la classe Properties peut répondre à ta question initiale, et suffit amplement pour stocker... de simples paramètres.

Burgergold : le problème vient du fait que je vais devoir modifier un ou deux paramètre(s) sur un fichier en contenant plusieurs centaines. Si je ne devais le faire qu'une fois je pourrais tout lire puis tout réécrire, mais je dois pouvoir faire cela un nombre répété de fois (beaucoup de threads).

Je ne pense pas que la classe properties convienne étant donné que je doit pouvoir stocker plusieur fois la même clé avec des valeurs différente dans le fichier.
 
Concrétement, mon fichier va contenir des informations (association clé - valeur) sur des données. Je veux pouvoir sauvegarder les informations sur toutes les données dans un unique fichier, avec des threads qui accèdent et modifient ces informations continuellement.

 
Dans ce cas, peut être qu'il te faudrait une représentation en mémoire de ton fichier avec des appels synchronisés pour lire les infos et les modifier. Et ensuite, tu permets à cette représentation de se sauvegarder sur disque de temps en temps (tous les x appels ou toutes les x minutes)

+1

C'est effectivement le plus logique (d'ailleur, je garde toujours une représentation en mémoire de mes données), cela permettant de n'effectuer qu'une seule lecture du fichier au lancement du programme. Mon problème est que je dois avoir un système resistant au panne, et si je ne sauvegarde pas au fur et à mesure il subsiste un risque de perte de données (coupure de courant entre deux sauvegardes par exemple)...

pour ton probleme ( para1=value1)
penses a utiliser la classe Properties, c l ideal pour ton pb.
 
salut

oui, mais je dois gérer des sections qui vont chacune contenir une clé para1... Et je ne pense pas que la classe Properties héritant de Hashtable permette de gérer cela (ou alors j'ai rien compris)

Effectivement, Properties risque d'être un peu limite. Je t'épargne mes suggestions quick & dirty particulièrement rapides à implémenter mais un peu bourrine (quoique) vu l'utilisation critique que tu annonces.
 
Si tu veux résister aux pannes, et qu'aucune perte de donnée en cours de route n'est admissible (même pas pour qq secondes d'exécution ?!), il va te falloir écrire chaque changement dans le fichier au fur et à mesure (le tout étant évidemment sérialisé, cela va sans dire).
 
Je doute que ce soit vraiment efficace. Tu vas même perdre le bénéfice de bufferiser. Ton accès fichier sera un bottleneck notoire.
 
A ce niveau là, et vu l'usage hyper intensif que tu prévoit, une DB ne serait-elle pas envisageable ? Ou accepter un compromis ?

La DB serait la meilleur solution (et sera sans doute la solution adoptée à terme). Mais il faut qu'au depart cela fonctionne sans (malheureusement).
Je pense qu'une solution envisageable serait d'ecrire au fur et à mesure les modifications à la fin d'un fichier comme un porc. Les information vont se retrouver en double dans le fichier, mais jepeux envisager un tache qui se lance régulièrement et qui fait le ménage (et là je peux utiliser une méthode plus lourde impliquant une réécriture entière du fichier)...

Ta procédure de cleanup te prendra sans doute autant de temps que de concevoir une écriture correcte dans le fichier dès le départ.

Sauf que je ne peux pas modifier une valeur au milieu du fichier sans avoir à réécrire toutes les données qui suivent. Par conséquent si j'ai 1 modification par seconde, je dois réécrire en moyenne la moitié du fichier chaque seconde
Si j'ecris juste à la fin, ça fait quelques lignes par seconde et une fois toutes les 5 minutes, je réécris le fichier en entier. Ca fait tout de meme moins de volume réparti sur le temps (surtout si le fichier fait plusieurs dizaines de Mo)

Dans ce cas, tu as raison... Mais ça va SUCKER à donf.

Ce que j'en dis c'est que :
1- tu travailles avec ta représentation mémoire de ton fichier (accès lecture/écriture)
2- Tu mets en place un thread qui se charge de sérializer ta représentation mémoire en permanence (dès que le thread termine la sauvegarde de ton fichier, il pompe le contenu de ton objet mémoire et le sérialize dans le fichier
3- Evidemment tu auras toujours un delta de un à qqs éléments
4- Tu n'as pas à te préoccuper des problemes de persistances et tu évites la lourdeur d'accès à un fichier

En somme c'est une question de trade-off perf/fiabilité/consistence.
 
Maintenant, si le thread sauvegarde le fichier en permanence (le traitement "mémoire" étant négligeable), ça va gratter sur le disque.

c'est aussi ce que je pense (le disque écrit en permanence). En plus comme c'est censé fonctionner sur un serveur de données avec pas mal d'accès en lecture/ecriture, ça risque de pas être top niveau performances...

Tu n'as pas trop le choix : accepter un delta contre un gain de perf, et/ou remplacer le fichier par une db.
 
Fichier indexé plutôt que séquentiel ?

 
Mouais, en gros tu veux le beurre, l'argent du beurre et le c*l de la crémière...

Ce qui n'est pas, en soi, mutuellement exclusif en informatique. Mais dans le cas d'espèce, hmmmm...

tu peux faire par exemple dans ton fichier properties:
appliname.section.sousSection.param=value
salut