Le lundi 19 septembre 2016 14:05:02 UTC+2, Cédric Krier a écrit :
>
> On 2016-09-19 13:34, Sergi Almacellas Abellana wrote: 
> > El 19/09/16 a les 10:26, Ali Kefia ha escrit: 
> > > We faced this problem last year and worked on scaling trytond this way 
> > > 
> > >   * Shared Cache on Redis 
> > >   * Load balance with Nginx 
> > >   * Sync mechanism via redis PUB/SUB to reload Pool 
> > > 
> > > Description of Coog (trytond spécialized ERP) 
> > > here: http://coopengo.com/coog-v1-6-nouvelle-architecture/ 
> > > Implementation on a trytond fork: https://github.com/coopengo/trytond 
> > > For more details or help using it, send me an email 
> > 
> > AFAIU you need the redis chache and the sync mechaninsm because you have 
> the 
> > wsgi servers running in different machines. Am I right? 
>
> You do not need anything for the cache even if it runs on different 
> machine. But memory for cache will be used per process. 
>

May be I missed something but it is worth asking a question:
When we have 2 workers, W1 and W2, working on an instance (call it a 
product), how to manage this situation:

   - W1 added product to cache (from database)
   - W2 modified product and cleared ITS product cache
   - W1 makes get on product cache => hit an invalid version

We can not check db on each cache.get call?
 

>
> The pool invalidation is not supported but as the module management is 
> slowly moved to trytond-admin. I think there are no needs to implement 
> it. 
>

I agree, we added it later to avoid loosing a native trytond feature 
(install module on the fly)
 

>
> -- 
> Cédric Krier - B2CK SPRL 
> Email/Jabber: cedric...@b2ck.com <javascript:> 
> Tel: +32 472 54 46 59 
> Website: http://www.b2ck.com/ 
>

-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/da7b526c-2e83-4b89-a5d7-e8996ef7a053%40googlegroups.com.

Reply via email to