Discussion :

[NiamorH]

Bonjour,

j'ai choisi XML comme stockage de données car j'ai peu de tables, peu de lignes et peu d'utilisateurs.

Jusqu'à présent je me contentais de faire un ReadXml() et WriteXml() à partir du DataSet, mais maintenant je veux gérer les accès concurrents.

Comment procéder ? Je ne vois pas d'adapter qui permettent d'aller modifier uniquement les nodes du Xml qui ont été modifiées. En fait je ne vois pas d'adapter du tout qui permette des opérations de mise à jour sur un Xml. Juste cette méthode barbare WriteXml qui me réécrit tout le fichier.

De même, j'aimerais pouvoir exécuter une requête sur mon fichier qui me retourne un DataSet.

D'avance merci.

[tomlev]

Jusqu'à présent je me contentais de faire un ReadXml() et WriteXml() à partir du DataSet, mais maintenant je veux gérer les accès concurrents.

Les accès concurrents entre quoi et quoi ? plusieurs process ? plusieurs threads ?

aller modifier uniquement les nodes du Xml qui ont été modifiées.

Euh...

En fait je ne vois pas d'adapter du tout qui permette des opérations de mise à jour sur un Xml.

Parce qu'il n'y en a pas

De même, j'aimerais pouvoir exécuter une requête sur mon fichier qui me retourne un DataSet.

Ben c'est pas prévu... le DataSet c'est plutôt pour les bases de données. Si tu veux tu peux toujours faire des requêtes sur ton XML et générer toi même une DataTable qui contient les résultats...

A mon avis tu devrais envisager l'utilisation d'une base de données, le XML est pas forcément très pratique pour ce que tu en fais. Ou alors tu utilises un DataSet que tu enregistres en XML, tu travailles juste sur le DataSet, et quand il est modifié tu le re-enregistres...

[NiamorH]

Concurrence entre plusieurs process. J'ai, disons, deux clients qui travaillent sur le même xml.

Ou alors tu utilises un DataSet que tu enregistres en XML, tu travailles juste sur le DataSet, et quand il est modifié tu le re-enregistres...

Ca c'est ce que je fais actuellement.

Je commence à voir que, XML, c'est pas la panacée que j'avais espéré pour ma petite appli toute bête... Même Linq -> XML semble ne pas vouloir m'aider.

[tomlev]

Pour gérer la concurrence entre 2 process, en général on utilise des Mutex : avant d'accéder au fichier, le process A tente de s'approprier le mutex, et le rends quand il a fini son traitement sur le fichier. Si un autre process B a déjà pris le mutex, A reste bloqué jusqu'à ce que B le libère.

Sinon, tu pourrais avoir un service WCF qui serait seul à accéder au fichier, et les process clients accèderaient juste au service, comme ça le service peut gérer la concurrence simplement entre ses différents threads avec des blocs lock

[NiamorH]

Oui, pas bête l'idée du serveur. Mon problème n'était pas vraiment de locker les ressources mais plutôt de devoir faire un merge des modifications sur le Xml qui me sert de base. (La méthode WriteXml des DataSet écrase purement et simplement l'ancien Xml...)

Un exemple tout bête de mon problème :

Hervé consulte la liste des produits (il a fait un select * de la table produit) et commence la création d'un produit.
Eva, pendant ce temps, met à jour un autre produit, en rajoute un deuxième et en supprime un troisième. Elle enregistre.
Si Hervé enregistre maintenant (via la méthode WriteXml), il va écraser les modifs d'Eva.

D'où mon soucis : il n'y pas de méthode prévue pour merger le contenu d'un DataSet et son Xml source.

Sachant qu'en utilisant un serveur, je pourrais y charger l'intégralité de ma base en mémoire (envisageable car pas énorme) puis accéder à des vues (toujours des datasets) via des requêtes formulées par les clients qui travailleraient sur les données en local et renverraient au serveur un dataset contenant les modifs que ce dernier serait chargé de merger avec le reste de la base. Chaque client pourrait à tout moment demander au serveur de sauver la base (via la méthode WriteXml) sans risque d'écraser les données de l'autre.

Ca me parait tenir la route mais tout de même un peu lourd à mettre en place (notamment la communication entre le serveur et les clients).

Qu'est-ce que tu en penses ?

WCF, jamais touché, c'est simple d'utilisation ? Adapté dans mon cas ?

[tomlev]

D'où mon soucis : il n'y pas de méthode prévue pour merger le contenu d'un DataSet et son Xml source.

Si : tu charges le fichier dans un autre dataset, tu merges les 2, et tu enregistres le résultat. Mais le problème de concurrence se pose toujours : un autre process fait la même chose au même moment. Là encore, tu peux régler ça avec un mutex

mais tout de même un peu lourd à mettre en place (notamment la communication entre le serveur et les clients).

Qu'est-ce que tu en penses ?

WCF, jamais touché, c'est simple d'utilisation ? Adapté dans mon cas ?

C'est relativement simple... il y a des tutos ici si tu veux :
http://dotnet.developpez.com/cours/?page=csharp#wcfcs
J'en sais pas vraiment assez sur ton appli pour te dire si c'est adapté, mais je ne vois pas de contre-indication a priori...

[MetalGeek]

Salut,
tu t'embêterais vraiment moins avec une base de données SQL. Le multithread, multiutilisateurs, bref multiXXX ça sonne toujours mal avec les fichiers plats - et XML, qui est excellent pour certaines situations, si t'en sers pour le stockage ça reste du texte, et un fichier plat.
Sinon tu gères tous les accès avec une classe statique, ou un singleton que tu vérouilles à mort avec des locks, mais il te restera à choisir une stratégie - en bref optimiste ou pessimiste. Ce genre de choix est fait, géré et sécurisé à ta place par une base de données SQL. EN plus si tu travailles avec des datasets, je pense que c'est vraiment le mieux.

[NiamorH]

Salut,

bien vu tomlev, il suffit que le client lock la ressource Xml, la charge dans un dataset et le merge avec celui qui est en mémoire, et le sauve puis relâche le lock. Pas besoin de sortir l'artillerie lourde en passant par un serveur.

Effectivement il y a des avantages à passer par une base de données (j'en vois pas tant que ça en fait), mais j'ai vraiment envie de voir jusqu'où je peux aller avec ce fameux fichier Xml. C'est pas comme si c'était pour le boulot, c'est juste une petite appli perso. Tant pis si je me trompe.

Pour ce qui est de la stratégie, si je passe par une base de données, je devrait de toute manière aussi la gérer par des locks sur des enregistrements, voire des tables entières / compteurs d'édition, non ?

Que m'apporte la base de données si je travaille avec des datasets ?