Ecriture concurrente dans un fichier

Bonjour à tous,

Je suis en train de créer un programme qui traitera des fichiers xml sur un serveur local. Mon problème étant que plusieurs personnes feront tourner ce programme, parfois en même temps, et dans ce cas là y aura un problème d'écriture concurrente.
J'ai fait quelques recherches avec mon ami et j'ai trouvé d'autres personnes qui avait ce genre de problèmes mais jamais exactement pour le même cas que moi (concurrence entre threads ou avec un servlet).

Je pense avoir trouvé la solution grace au package NIO mais j'aimerais avoir une confirmation pour ne pas me lancer à corps perdu dans un travail qui ne servira à rien au final :s

D'avance merci !

Pourquoi ne pas utiliser une base de données plutot qu'un fichier ? C'est à ca que ca sert, ca evitera de réinventer la roue et ca sera plus efficace ;)

Oui je sais, c'est ce que je me suis dit quand on m'a présenter le travail à réaliser, mais visiblement ça n'est pas possible pour des raisons logistiques -__-

Mais effectivement je m'étais plutôt tourné vers de la persistence parce que y'a pas mieux pour ce genre de truc. Du coup je me retrouve à faire du XML relationnel au feeling (j'apprends sur le tas)

Honnêtement les problèmes de cohérence et synchronisation sont extrêmement complexes à gérer. Autant à la conception qu'au débogage. Je ne me risquerai pas à essayer de faire mon propre système dessus.

Ha..

Ca veut dire qu'il n'existe pas de méthode pour gérer un tel système ? Ce serait embêtant...

Le seul systeme fiable consiste à passer par un programme intermediaire qui gere les transactions (en gros, ce que fait la BDD). Avec des fichiers, tu peux toujours bidouiller en créant par exemple un fichier lock pour indiquer aux autres programmes que tu es en train d'ecrire mais ca vaut ce que ca vaut...
Apres, ca depend du risque qui est accepté. Soit on veut un truc fiable qui marche et c'est BDD. Soit une bidouille qui marchera 99% du temps mais qui peut poser probleme 1%.

He bien à priori les autres programmes qui y accederont ce sera celui que j'ai developpé. Il sera utilisé par plusieurs personnes sur le réseau pour consulter et, occasionnellement, modifier les fichiers xml.

Donc normalement je devrais pouvoir me débrouiller non ? Ces fichiers ne devront (enfin, ne sont pas prévus pour le moment) pas être modifiés par d'autres programmes

Disons qu'en théorie rien ne t'empêche de faire ton propre algo de mutex, mais que c'est super galère et qu'aucun ne t'est fourni, faut le faire soi-même.
Pas pour des fichiers sur le réseau en Java, en tout cas.

D'où l'idée de dire merde à ces soi-disant "raisons logistiques" qui existent pas, et d'utiliser la solution à ce problème la plus simple connue depuis plus de trente ans : une base de données.
Ou alors d'accepter un risque, et prévoir des outils de réparation dans ce cas.

L'idée de m**** n'est pas besoin mais je suis obligé de faire avec :cry:

J'essaierai de trouver un moyen efficace de contourner le problème où alors je me prendrais vraiment la tête à faire un algo de mutex...

Je songeais à utiliser ce que j'ai pu trouver là dessus sur Internet.

Et faire un truc assez simple, je lock tout le fichier le temps de l'écriture et si un utilisateur essaie d'écrire en même temps, un pop-up lui indique d'attendre quelques instants avant de réécrire. Faut juste que je vois si ça lock aussi en écriture ou pas, car dans ce cas je dois trouver autre chose

Citation:

---

ça n'est pas possible pour des raisons logistiques

---

Je n'arrive pas à imaginer quelles "raisons logistiques" pourraient empêcher d'utiliser une BDD... Je serais à ta place, je discuterais. Dans tous les cas de figure, ce que tu t'apprête apparemment à faire, c'est ça [une BDD], de toutes façons, sauf que tu vas devoir réécrire des tas de choses, et qu'il y aura plein de bugs.

Tu viens de dire le mot magique "en réseau". Rien que ça, c'est foutu. Pour info, SQLLite, qui est à ma connaissance la seule base de donnée implémentant un locking fiable permettant à plusieurs processe d'ouvrir simultanément de le fichier de base (pour éviter d'avoir un "serveur" base de données), et qui utilise les systèmes de verrou des OS pour garantir l'exclusivité des écriture... Et incapable de fonctionner fiablement sur un montage réseau. Dès que t'as un montage réseau, il n'existe plus aucune technique fiale de locking des fichiers. Deux process peuvent créer, avec succès, le même fichier lock en même temps, sur deux OS séparés par exemple.

Les systèmes de locking liés à l'OS sont locaux à la machine.

Je ne sais pas quelles sont tes contraintes logistiques. Quant je relis le problème de base, je passerait par un service RMI (ou corba) pour proposer le service de modification. En utilisant un mutex (simple) tu a ta synchronisation. Le tout sans BDD.

Après si tu nous donne les contraintes on pourra répondre de manière plus précise.

Citation:

---

Envoyé par forthx

Je ne sais pas quelles sont tes contraintes logistiques. Quant je relis le problème de base, je passerait par un service RMI (ou corba) pour proposer le service de modification. En utilisant un mutex (simple) tu a ta synchronisation. Le tout sans BDD.

---

-_-°... Euh... La différence avec une BDD me semble pas évidente. C'est juste moins pratique qu'une vraie BDD.

Tu es au courant, au passage, qu'il existe des bases de données pure java qui ne nécessitent pas d'installation? tu la fais tourner sur le serveur et tout le monde l'utilise via le réseau...

Ouais, ptet qu'un serveur SVN suffirait, en fait...

Woah, merci pour vos réponses.

Le problème c'est que je suis en stage sur un gros site dont la gestion informatique est délocalisée. De plus, je ne suis pas dans le département, je developpe un outil pour l'un des employés. Il a un fichier Excel qui répondait à ses besoins jusque là mais maintenant il désire quelque chose de plus adapté. Les raisons qui me poussent à ne pas faire d'installation sur le réseau sont que ça prendrait visiblement beaucoup de temps pour qu'ils soit sûr que ce que je fais et sûr, d'autres part, et quasiment le plus important, parce qu'il est indiqué dans le cahier des charges que je ne dois pas mettre ce genre de truc en place.

Autre chose à laquelle j'avais songé, c'est d'utiliser Hibernate, parce que je croyais qu'il permettait de réaliser ce que je veux, mais il semblerait que je me sois trompé et que ce ne soit que le schéma relationnel qui soit en XML. Corrigez moi si je me trompe

(Je ne suis qu'étudiant d'IUT, il m'arrive de dire des conneries...)

Donc si je résume.

Tu dois créer une application pour 1 personne.
Qui va tourner potentiellement sur plusieurs machine (ça ne me parait pas logique)
Qui ne peux pas être un serveur parce que ce n'est pas autorisé par l'autorité centrale
Mais qui a tout à fait le droit de se servir du réseau, d'y lire / écrire des fichiers (encore une fois ça me paraît incompatible).

Note que si t'as que 4 utilisateurs dans le même bureau -> Dit leur de ne pas bosser en même temps? Sinon, ben il faudra admettre les risque de corruption puisqu'on ne t'autorise pas à mettre en place des verrous efficaces.

Le probleme n'est pas xml, json, hibernate ou leurs copains. C'est l'acces potentiellement simultané à un fichier par différentes machines reseau. La seule maniere d'etre sur que ca fonctionne est d'utiliser un programme qui gere l'acces. Et, coup de bol, c'est ce que fait une BDD. Donc, il faut soit utiliser une BDD, soit accepter les problemes eventuels. Apres tout, en mettant en place un systeme de sauvegarde, tu peux t'en sortir. Le nombre d'utilisateurs n'etant pas tres élevé, ca peut suffire.
C'est comme en cuisine. Si tu coupes une carotte avec une fourchette, faut pas s'attendre à ce qu'elle soit bien coupée ;)

Après, si c'est juste pour modifier des fichiers XML de manière concurrente, un serveur SVN fait l'affaire... Du coup la réconciliation entre les eventuelles versions est gérée par les users.

Mais en effet, on comprend mal pourquoi il y a une histoire de modifs concurrentes, s'il y a un seul utilisateur. Par ailleurs, s'il utilisait excel pour faire ça, en principe c'est un lock par fichier, je pense.

En gros, mon tuteur de stage, qui est l'utilisateur principal, a créée un fichier excel qui contient des données sur différents départements du site. Ce fichier est consulté par d'autres personnes (des départements concernés), qui peuvent modifier certains champs du fichiers (pour les prévisions par exemple).

Désolé pour le manque d'informations, vu que je suis en stage dans une société privée, je ne sais pas quelles sont les informations que je peux transmettre sans me faire taper sur les doigts :x


EDIT : du coup je vais faire une application où mon tuteur sera administrateur, et les autres utilisateurs seront des utilisateurs qui auront certains droits. L'idée de base étant de faire tout ça avec des fichiers xml

Normalement, on fait ça avec une base de données, il n'y a aucune raison logique de ne pas le faire. A la base, faire ça avec un fichier excel est une erreur (voire une faute...).

Je ferais une BDD avec entre autres une liste de users, et ce qu'ils peuvent faire comme modifs, avec un admin qui peut faire ce qu'il veut. Rien que des choses très banales, ça n'a vraiment rien de très particulier comme appli, c'est même hyper-classique depuis au moins les années 1960. Ton tuteur de stage n'est pas développeur, visiblement... Rien que l'idée de faire ça sous excel est absurde, alors que Access, déjà, fait ça mieux. D'ailleurs, en fait, le mieux c'est d'utilsier Access, à mon avis.

Encore une fois, le probleme ne vient pas de xml ou de droits qu'auront ou pas les utilisateurs. A partir du moment ou il peut y avoir 2 personnes qui modifient un meme fichier, il y a un risque en cas de modification simultanée. Il faut donc voir avec ton tuteur si le risque de corruption de données est acceptable. Et si non, utiliser une BDD. Il n'y a pas 36000 solutions. On peut tourner autour du pot encore longtemps, en parlant de droits, de sécurité ou de serveur mais on en reviendra toujours au meme point.

Trés bien merci,
Je vais essayer de négocier ça avec lui, je reviendrai vous dire ce qu'il m'a dit :coucou:

Au passage, faire une petite application "serveur" qui tournerais sur la machine du tuteur en démarrage automatique. C'est moche, c'est anti production, mais au moins, le problème de concurrence est réglé.

De plus, si chacun peux changer des données différents, il serait plutot préférable de partir de l'idée que chaque "employé" a son propre fichier avec uniquement ses données et que l'application merge ces fichiers à l'écran, non?

Citation:

---

Envoyé par BenWillard

D'ailleurs, en fait, le mieux c'est d'utilsier Access, à mon avis.

---

Je plussoie

... si les postes sont sous Windows.

Cela me fait bizarre dans un forum java de recommander Access mais, si tu connais un peu Access, tu vas pouvoir régler le problème en deux coups de cuillère à pot.

Attention que, si le réseau est controlé par l'administration centrale, une base de données access, autant que je sache, a la réputation de pas mal "crier" sur le réseau :)

Bonjour Tchize

Qu'entends-tu par crier ?

beaucoup de broadcast :)

Ah ben ça c'est possible.

La gestion de verrou par Access se fait avec un petit fichier ldb placé à côté de la base mdb.
Dans ce système, il n'y a pas de serveur de base et les accès concurrents sont gérés par chaque Access installés sur les postes !

En pratique ça marche bien tant qu'on ne dépasse pas une dizaine d'utilisateurs.
Donc pour @Carvallegro cela devrait convenir s'il ne trouve pas son bonheur avec Java.

En java, il est clair que la solution la moins mauvaise est celle que tu as suggéré :
- le fichier XML installé sur un poste
- une application serveur en java qui attend les requêtes des utilisateurs sur un port convenu
et qui se charge des ajouts/modifications/suppressions/consultation
- l'application cliente (sur les postes) qui communique avec le serveur par socket

Citation:

---

Envoyé par Népomucène

Ah ben ça c'est possible.

La gestion de verrou par Access se fait avec un petit fichier ldb placé à côté de la base mdb.

---

T'es sûr qu'il n'y a que ça? Parce que, dans l'absolu, ce n'est pas fiable. tu pourrais avoir 2 poste qui crée ce fichier en même temps. Le protocole CIFS dans certaines condition va laisser passer.... C'est justement ce qui empêche SQLLite de travailler en montage réseau :/

Ben oui.
Ce fichier est créé lors du premier accès à la base mdb par Access.
Ensuite chaque utilisateur qui se connecte sera enregistré dans le ldb avec des infos de sécurités
et des locks sur des pages de données (je n'ai pas les détails mais en gros c'est ça. Plus d'info : http://support.microsoft.com/kb/208778/fr)

Après, quand tout le monde est parti, le fichier ldb est supprimé.

Le système n'est théoriquement pas idéal mais franchement, après l'avoir utilisé pendant des années
les plantages sont rares à condition de bien concevoir la base.
J'ai même fait une gestion de production pour une usine qui tournait 24h/24h avec une base Access.
Il n'y avait que 20 postes de connectés (cela dit, après 3 ans d'utilisation, on est quand même passé à Oracle).

Il est clair que la solution Access est limitée à quelques utilisateurs.