polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislav Muhametsin <stanislav.muhamet...@zest.mail.kapsi.fi>
Subject Re: cache mechanism?
Date Tue, 03 May 2016 19:32:06 GMT
I think Paul was more involved with SQL EntityStore (while I was 
crunching out the SQL Indexing), so he might help with this.
IIRC, JSONMapEntityStoreMixin at least back then (if it was even called 
like that) had some issues which made it unusable with SQL ES.

On 03/05/2016 16:50, Niclas Hedhman wrote:
> 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.

View raw message