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: Hangout on Monday 19 June
Date Mon, 17 Jul 2017 09:47:29 GMT
Hi guys,

It's my first day in office after a vacation, and it looks like I got so 
much to do, that I won't be able to participate in the meeting.
Sorry about that, but I hope to be present on next one! :)

On 3.7.2017 21:01, Paul Merlin wrote:
> 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!
>
> Cheers
>
> /Paul
>
>
>


Mime
View raw message