[pyar] Caché para clusters?

[QliX=D! [aka EHB]]

Es que si el dirty lo notificas justo cuando se termino de serializar la
data al memcache de P1 no importa si el proceso muere... el memcache va a
replicar el valor en cuanto pueda sobre todos los demas. Por eso te decia
de usar multimaster para la replicacion del los valores. Asi el dato esta
disponible en todos los nodos y el recalculo lo puede seguir cualquiera.
A eso agregale nodos que hagan de controlers para validar que los
recalculos sean atomicos y tenes algo masenos usable... al menos
conceptualmente.
El may 10, 2013 7:05 PM, "Claudio Freire" <klaussfreire en gmail.com> escribió:

> 2013/5/10 QliX=D! [aka EHB] <qlixed en gmail.com>:
> > Y si a eso le agregas una notificacion de dirty? Asi P1 al cambiar los
> datos
> > vos le avisas a todos los Pn que esa haskey esta modificada...
> > Asi durante el tiempo t que tarda en serializar un memcache de un equipo
> al
> > otro los Pn ya saben que tienen que esperar, o que le tienen que pedir a
> P1
> > la vopua de hashkey...
>
>
> Ese es mi plan, pero no es tan sencillo evitar duplicación de trabajo.
> Si se notifica el dirty, y Pn vuela la entrada del cache, cuando la
> necesite va a calcularlo. Lo ideal es que se notifique un "pending", y
> que Pn espere. El problema que tengo que solucionar, es qué pasa si P1
> se muere mientras está calculando... ¿cómo hacer que Pn se entere
> rápido y tome la posta?
>
> Estoy leyendo ZooKeeper a ver si atacan ese problema. No parece.
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130510/d77fdc35/attachment.html>