polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "zhuangmz08" <zhuangm...@qq.com>
Subject 回复: cache mechanism?
Date Tue, 03 May 2016 07:33:38 GMT
Thanks to Kent, I deleted the Cache Layer and build a cache module in the Persist Layer. I
found that SQL entities doesn't support caching. Only JSONMapEntityStoreMixin support caching?





------------------ 原始邮件 ------------------
发件人: "Niclas Hedhman";<hedhman@gmail.com>;
发送时间: 2016年4月28日(星期四) 晚上9:41
收件人: "dev"<dev@zest.apache.org>; 

主题: Re: cache mechanism?



Adding to Kent's good answer;

1. I think Kebt wasn't explicit enough; You shouldn't have a Caching Layer.
Caching is part of the persistence and should be in the same layer.

2. Indexing isn't synchronous with persistence, it is what is called
Eventually Consistent. You even have a lot of custom control over how it
should work. But it means that if you run a query within a UnitOfWork the
indexing has not yet seen the "current" changes, and even if you run it
directly after .complete(), you might not get the latest changes yet. Mind
you, I have some thoughts about making some changes in how all of this
works, so ot might change in 3.0 to some degree (or not).

Niclas


On Apr 28, 2016 14:43, "Kent Sølvsten" <kent.soelvsten@gmail.com> wrote:

> Hi
>
> The cache is wrapping the EntityStore (in your case the Postgres access)
> - if you happen to be familiar to eg. Hibernate, it is similar to a
> Hibernate level 2 cache.
>
> This means:
>
> If you create a new entity, the entity will  be created at the cache at
> uow.complete() - immediately after writing to postgres.
> If you load an existing entity (by id) the cache is checked before
> reading from Postgres.
> Updating that entity is similar to creation: the cache will be updated
> at uow.complete() - nothing happens when the entity becomes "dirty".
>
> Querying is a bit more complex:
> When you query for entities, under the hood the query will be performed
> against an indexer returning references (id's) for entities.
> These references are converted to full entities using either the cache
> or postgres.
>
> So the short story: The cache should contain the same state as your
> Postgres entitystore.
>
> Another thing is that in you configuration, the EntityStore should have
> access to the cache - otherwise the cache will simply be silently
> ignored by the persistence mechanism.
>
> /Kent
>
>
> Den 28-04-2016 kl. 07:21 skrev zhuangmz08:
> > Hi,
> >
> >
> > I would like to assembling the following layers (from up to bottm)
> [Domain Layer] [Cache Layer (memcached)] [Persist Layer(entity store /
> index query)] [Config Layer].
> > I can assemble this layers correctly. I can use
> (domainModule.newUnitOfWork) to write and query data. I can find the
> entities stored in Postgres.
> > However, I'm confused about caching mechanism here?
> > When did the system put entity into cache? When newEntityInstance and
> uow.complete? When newQurey.find and uow.complete?
> > When did the system update the cache? When entity.property.set and
> uow.complete?
> >
> >
> > Thanks a lot.
>
>
Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message