Je suis sur le point de développer un service Windows en C #. Ce service doit garder une trace des événements du système et écrire des données aux fichiers de temps à autre. Ces événements en cours forment un certain état, donc je vais garder l'état en mémoire et le mettre à jour comme des événements arriveront. Je ne veux pas trop compliquer les choses, je ne veux donc pas que l'État soit persistant sur le disque, mais je me demande si je pouvais en quelque sorte le rendre persistant en mémoire, de sorte que si le service se bloque (et redémarre automatiquement par Windows) Cela pourrait capter là où il est parti et continuer (éventuellement perdre des événements, pas une grosse affaire).
Je pensais dans la ligne de création d'une zone de mémoire "partagée", laissant ainsi les fenêtres le gérer et l'utiliser uniquement dans le service - mais je ne suis pas sûr que l'objet persiste après la mort du service.
Des idées?
6 Réponses :
Que diriez-vous d'utiliser un stockage isolé et de persister l'objet dans la mémoire de cette façon?
Pouvez-vous élaborer sur "stockage isolé"?
Consultez le lien Ondotnet.com/pub/a/dotnet/ 2003/04/12 / isoléeStorage.html
Merci d'enrichir mes connaissances. Cependant, cela écrit également dans les fichiers - et je n'ai aucun problème d'autorisation, le stockage isolé n'ajoute pas de valeur à ma situation.
Vous pouvez utiliser Memcached ou ReDIS (qui persiste également, il s'agit de données sur le disque, mais les gère automatiquement).
http://code.google.com/p/redis/
Vous pouvez également jeter un coup d'oeil à cette question:
Memcached et Redis sont intéressants de savoir en effet, mais j'ai un sentiment qu'ils seront une overkilleuse. Je n'ai besoin que de stocker comme quelques objets avec plusieurs cordes et entiers. Je pourrais le faire avec l'interaction du disque, mais je préfère l'interaction de la mémoire pour des raisons évidentes. Je cherchais une fonctionnalité intégrée dans .NET ou Windows.
Eh bien, vous pouvez essayer d'essayer de décider si votre sentiment est correct ... Quoi qu'il en soit, les conseils de JM Servera d'utiliser le bloc de cache de persistance peuvent être une bonne option pour vous.
Même si, par exemple, vous conservez les données sur une mémoire partagée d'un autre PC réseau , comment "garantir" que le PC réseau ne sera pas suspendu / Redémarrez / HALT / ETC? Dans ce cas, votre service perdra de toute façon les données persistées.
Je suggérerais et les chances sont susceptibles de vous retrouver, stocker les données sur le même disque.
Notez que, en raison de la nature volatile de la mémoire (RAM), vous ne pouvez pas recharger des données précédemment présentes, avant le redémarrage du système; pas à moins que vous n'utilisiez un mécanisme pour stocker / recharger sur le disque.
Dans ce cas, que diriez-vous d'utiliser MSMQ ? Donc, vous pouvez tout pousser sur la file d'attente et même si votre service reçoit un redémarrage, il rechercherait les éléments de la file d'attente et continuerait à partir.
Si le même PC redémarre, je n'ai plus besoin des données persistantes. Je veux couvrir uniquement le cas extrême dans lequel mon service se bloque et redémarre automatiquement.
Je ne vois pas pourquoi il serait plus difficile de persister le disque.
en utilisant DB4O Vous pouvez persister les instances que vous travaillez déjà.
Il n'est pas difficile de persister le disque. Mes données sont très simples et je peux facilement le sérialiser à partir d'un fichier, je veux simplement éviter de jouer avec le disque si possible. Les données ne sont pas si importantes; Si je peux travailler avec tout de même, gardez la mémoire en sécurité (plus sûre ...) pour le court laps de temps lorsque le service est malheureusement redémarré, ce serait génial.
Gérer les scénarios de défaillance attendus évitant l'utilisation inutile du redémarrage automatique et l'ignorer pour le scénario extrême qui se bloque toujours / puisque vous avez déjà dit si la boîte est redémarrée, vous ne vous souciez pas de perdre les données.
Eh bien, cela espère le meilleur :-) évidemment, je ne vais pas coder comme je m'en fiche si le service survit. Je ferai de mon mieux pour le garder, et toujours ... mais je dois peser dans le coût de persister les données.
Je suis désolé, mais il y a quelque chose de très étrange dans la façon dont vous en parlez. Soit vous vous souciez des données ou que vous ne le faites pas. Si vous vous souciez des données, persistez! Une fermeture inattendue de la boîte se produira, vous pouvez compter dessus. Je vous suggère que vous devriez mettre à jour la question et fournir plus d'informations sur votre scénario.
Mon raisonnement est comme ça - je voudrais persister les données si et seulement si cela n'aboutit pas trop de travail dans Dev Time ou Runtime. Sinon, je ne le ferai pas et je l'accepterai comme une limitation raisonnable du système. Je vais le rendre plus clair dans la question.
Vous pouvez utiliser un bloc de mise en cache perstituant à partir du Microsoft Enterprise Library .
Il est configurable et vous pouvez utiliser de nombreux magasins de support tels que la base de données et le stockage isolé.
Je sais que vous avez dit que vous ne voulez pas trop compliquer les choses en le persistant à un disque, mais cela va certainement trop compliquer pour persister les choses dans la mémoire partagée ou l'une des solutions énumérées ici. La raison pour laquelle de nombreuses applications utilisent des bases de données ou un stockage de fichiers sont parce que c'est la solution la plus simple.
Je vous recommanderais de garder tout l'état dans un seul objet ou une hiérarchie d'objet, sérialisez cet objet à XML et écrivez-le à un fichier. Cela n'obtient vraiment pas beaucoup plus simple que ça.
Je suppose que vous avez raison. Ma ligne de pensée était - ce n'est pas une donnée très importante, je peux vivre avec la perte. Si je pouvais modifier quelque chose dans mon code pour le rendre persistant pendant que mon service tombe et sauvegarde, sans changer beaucoup plus que cela, j'aimerais cela.
Ouais je ne pense pas que tu as vraiment cette option. Vous pouvez le rédiger périodiquement sur le disque, mais vous ne pouvez pas la persister juste avant que le service ne diminue - par exemple, si votre serveur s'écrase, il est déjà trop tard.