polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <paulmer...@apache.org>
Subject Re: Hangout on Monday 19 June
Date Mon, 03 Jul 2017 18:01:23 GMT
Thanks a ton for the summary Niclas!

Niclas Hedhman a écrit :
> Gang,
> Should have done this earlier, but been quite busy.
> First of all, remarkably the time was almost right. Tibor pointed out that
> CET is the non-DST timezone name. I should probably used Europe/Berlin or
> Europe/Paris.

Fraking timezones! :)

> Participants;
>  - Niclas Hedhman
>  - Tibor Mlynarik
>  - Stanislav Muhametsin (no cam/mic)
> Tibor came with a list of things, after trying to port his 2.x application
> to 3.x
> * @Uses disallowing Composites breaks his app. And it worked before. I
> realized from his feedback that I forbade a much wider usecase than the one
> that is a problem. Need to revert. Tibor, please add Jira issue. Or reopen
> the one from before.
> * Tibor felt a bit confused on how the State in composites really work
> under the hood. And he would like documentation on that. I tried to explain
> it in person, but add a Jira, and I will look into writing it up sooner or
> later.
> * I have a note on "UnitOfWork closed inconsistently", but can't recall
> what that was about.
> * ConcurrentModification checks might not work in clustered setups. Tibor
> suspects that the "version" is not checked against the store, and if it is,
> transaction-free stores have no chance to do a "Compare/Set" operation if
> that is supported (such as MongoDb has). I find this one particularly
> interesting, and would like investigate if we can improve the EntityStore
> SPI to take such into consideration in some manner.

Yep, the MapEntityStore SPI already provides means for implementors to
back this with some optimistic locking, see `previousVersion` and
`newVersion` in MapEntityStore.MapChange. The k/v SQL EntityStore uses
this. I think it's the sole one.

We could also consider moving this capability to the EntityStore SPI.

> * Indexing state change notification sent before commit. Possibly having a
> time window when the index has a new value, but the entity doesn't yet. I
> don't think this is a priority issue, since there is also the thing about
> isolation of transactions and caching on stores, which will also give a
> similar result, i.e. "find entities with sales > 10000" and one of those
> are in the UoW cache, with a value less than 10000. Additionally, the
> indexing may be asynchronous, operate on clusters, just like the ES might
> do, with unpredictable delays everywhere.
> Eventual consistency should perhaps be promoted more in Polygene and make
> this as transparent as possible.

Having the indexing after commit makes more sense to me. It would be
eventually consistent anyway depending on the peculiarities of your
application and the systems it uses. But if the commit fails, then
indexing would not be notified, which is good.

I recall state change notification being sent after commit. It changed
at some point and don't remember why. Any idea? Am I wrong?

Adding any sort of time based thing doesn't sound good to me.
> If Tibor's list contained anything else, I didn't take a note of it,
> perhaps he can fill it in.
> Other than that, some general chitchat and non-distinct ideas.
> Hope to see more people on July 17th 2017. Stan promises to arrange cam/mic
> by that time. :-)
> Cheers and see you all next time.

I expect to be present next time!



View raw message