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 <[email protected]> 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";<[email protected]>; > 发送时间: 2016年4月28日(星期四) 晚上9:41 > 收件人: "dev"<[email protected]>; > > 主题: 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" <[email protected]> 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
