Hangout on Monday 19 June

[Niclas Hedhman <ni...@hedhman.org>]

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.

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.

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

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.
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Hangout on Monday 19 June

[Stanislav Muhametsin <st...@zest.mail.kapsi.fi>]

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

Re: Hangout on Monday 19 June

[Paul Merlin <pa...@apache.org>]

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