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.
