Current caching

[Dominik Ruf]

Thanks for still helping the project.
That helped.

On Thu, Feb 1, 2018, 09:04 Marcin Kuzminski <marcin at python-blog.com> wrote:

> Hi Dominik,
>
> The database table is used for invalidation multiple processes. e.g if you
> run 3 workers via gunicorn each of them will register an entry in cache
> invalidation. This way if a push occurs in one process others will to
> invalidate it’s cache.
>
> This is mainly driven by the problem that some caches need to uses memory
> type which cannot be shared process wise because of serialization problems.
>
> Best,
>
> --
> Marcin Kuzminski
> RhodeCode, Inc.
>
> Enterprise Source Code Management. Unified.
> Contact us: Web <https://rhodecode.com/> • Twitter
> <https://twitter.com/rhodecode> • Community
> <http://community.rhodecode.com/> • Slack <https://rhodecode.com/join>
>
> On Thu, Feb 1, 2018 at 0:50, Dominik Ruf <dominikruf at gmail.com> wrote:
>
> Hi all,
>
> I'm currently looking at the caching Kallithea does. And I'm a
> bit...baffled.
> The way I understand it is that first an entry is made to
> CacheInvalidation to mark a cache invalid,
> and later that entry is checked to decide if that cache should be
> invalidated.
> But why this detour? Why not invalidate the cache directly?
> Can somebody explain to me why the invalidation is done via the
> CacheInvalidation table?
>
> cheers
> Dominik
>
> _______________________________________________ kallithea-general mailing
> list kallithea-general at sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20180201/982b3585/attachment.html>