polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: cache mechanism?
Date Tue, 03 May 2016 13:50:48 GMT
I just checked, and yes you are right, the SQL EntityStore isn't using
JSONMapEntityStoreMixin nor does it use the Cache SPI.

I suggest that you add a Jira issue (if it doesn't already exist) and if
you are a bit daring perhaps help out fixing it ;-)

Cheers
Niclas

On Tue, May 3, 2016 at 3:33 PM, zhuangmz08 <zhuangmz08@qq.com> wrote:

> 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.
> >
> >
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message