2010-09-16 23 views
7

Estoy a punto de desarrollar un servicio de Windows en C#. Este servicio necesita realizar un seguimiento de los eventos en el sistema y escribir algunos datos en los archivos de vez en cuando. Estos eventos en curso forman un cierto estado, por lo que voy a mantener el estado en la memoria y actualizarlo a medida que lleguen los eventos. No quiero complicar demasiado las cosas, así que no quiero que el estado sea persistente en el disco, pero me pregunto si de alguna manera podría hacerlo persistente en la memoria, de modo que si el servicio falla (y se reinicia automáticamente Windows) podría continuar desde donde salió y continuar (posiblemente perdiendo algunos eventos, no es un gran problema).Mantener datos persistentes en la memoria

yo estaba pensando a lo largo de la línea de crear un área de memoria "compartida", permitiendo así que Windows administre, y usarlo sólo en el servicio - pero no estoy seguro de que objeto se mantendrá después del servicio muere.

¿Alguna idea?

EDIT: No estoy buscando una solución exagerada. Los datos son algo importantes, así que me gustaría mantenerlos esperando en la memoria hasta que se reinicie el servicio, pero los datos tampoco son importantes. Es más una característica agradable de tener si puedo persistir los datos fácilmente, sin trabajar con archivos, procesos externos de terceros, etc. Mi solución ideal sería una característica incorporada simple (en .NET o en Windows) que me proporcione cierta persistencia dentro de la memoria, solo para recuperarse de un evento de bloqueo.

+0

Pago y envío: ['PersistentDictionary'] (http://izlooite.blogspot.com/2011/04/persistent-dictionary.html) clase –

Respuesta

3

Puede usar un bloque de almacenamiento en caché persitente del Microsoft Enterprise Library.

Es configurable y puede usar muchas tiendas de respaldo como base de datos y almacenamiento aislado.

+0

Bien, eso se ve muy interesante, ¡gracias! –

0

¿Qué le parece usar el almacenamiento aislado y persistir el objeto en la memoria de esa manera?

+0

¿Puede profundizar en el" almacenamiento aislado "? –

+1

Revise el enlace http://ondotnet.com/pub/a/dotnet/2003/04/21/isolatedstorage.html – Madeleine

+0

Gracias por enriquecer mi conocimiento. Sin embargo, esto también está escribiendo en archivos, y no tengo ningún problema de permisos, por lo que el almacenamiento aislado no agrega valor a mi situación. –

2

Puede usar Memcached o Redis (que también conserva los datos en el disco, pero los maneja automáticamente).

http://code.google.com/p/redis/

También puede echar un vistazo a esta pregunta:

Memcached with Windows and .NET

+1

Memcached y Redis son interesantes de conocer, pero tengo la sensación de que serán un exceso. Solo necesito almacenar como algunos objetos con varias cadenas y enteros. Podría hacerlo con interacción de disco, pero prefiero la interacción de memoria por razones obvias. Estaba buscando una característica incorporada en .NET o Windows. –

+0

Bueno, puedes intentarlo y luego decidir si te sientes bien ... de todos modos, el consejo de jmservera para usar Persistentc Caching Block puede ser una buena opción para ti. – mamoo

0

Incluso si, por ejemplo, a mantener los datos en una memoria compartida de algún otro PC en red , ¿cómo "garantizarías" que la PC en red no se cuelgue/reinicie/para/etc? En ese caso, su servicio perderá los datos persistentes de todos modos.

Sugeriría, y es probable que termine almacenando los datos en el mismo disco.

Tenga en cuenta que, debido a la naturaleza volátil de la memoria (RAM) no puede volver a cargar los datos que estaban allí antes de que el sistema se reinicie; no, a menos que use algún mecanismo para almacenar/recargar en el disco.

--EDIT--

En ese caso, ¿cómo sobre el uso de MSMQ? Por lo tanto, puede enviar todo por la cola e, incluso si su servicio se reinicia, buscará los artículos en la cola y continuará en adelante.

+0

Si la misma PC se reinicia, ya no necesito la información persistente. Quiero cubrir solo el caso extremo en el que mi servicio falla y se reinicia automáticamente. –

+0

@ Eldad: Consulte mi edición en respuesta a su comentario. –

1

No veo por qué sería más difícil de persistir en el disco.

usando db4o puede persistir las instancias con las que ya está trabajando.

+0

No es más difícil de persistir en el disco. Mis datos son muy simples y puedo serializarlos fácilmente desde y hacia un archivo, solo quiero evitar jugar con el disco si es posible. La información no es tan importante; si puedo trabajar de todos modos pero mantener la memoria segura (más segura ...) durante el corto período de tiempo en que desafortunadamente el servicio se reinicia, sería genial. –

+0

maneje escenarios de fallas esperadas evitando el uso innecesario del reinicio automático, e ignórelo para el escenario extremo en el que todavía falla/ya que usted dijo si la caja se reinicia no le importa perder los datos. – eglasius

+0

Bueno, eso es esperar lo mejor :-) Obviamente no voy a codificar como si no me importara si el servicio sobrevive. Haré todo lo posible para mantener el ritmo, y aún así ... Pero sí tengo que sopesar el costo de persistir en los datos. –

3

Sé que dijiste que no querías complicar demasiado las cosas guardándolo en el disco, pero definitivamente va a ser mucho más complicado conservar cosas en la memoria compartida o en cualquiera de las soluciones que se enumeran aquí. La razón por la cual tantas aplicaciones usan bases de datos o almacenamiento de archivos es porque es la solución más simple.

Le recomendaría que mantenga todo el estado en un solo objeto o jerarquía de objetos, serialice este objeto a XML y escríbalo en un archivo. Realmente no es mucho más simple que eso.

+0

Supongo que tienes razón. Mi línea de pensamiento era: este no es un dato MUY importante, puedo vivir perdiéndolo. Si pudiera modificar algo en mi código para hacerlo persistente mientras mi servicio baja y realiza una copia de seguridad, sin cambiar mucho más que eso, me gustaría. –

+1

Sí, no creo que realmente tenga esa opción. Puede escribirlo periódicamente en el disco, pero no puede mantenerlo justo antes de que se cancele el servicio; por ejemplo, si su servidor falla, ya es demasiado tarde. –

Cuestiones relacionadas