[infinispan-dev] Write-only commands

[Radim Vansa]

On 06/27/2017 03:54 PM, Dan Berindei wrote:
> On Tue, Jun 27, 2017 at 2:43 PM, Adrian Nistor <anistor at redhat.com> wrote:
>> I've said this in a previous thread on this same issue, I will repeat myself
>> as many times as needed.
>>
>> Continuous queries require the previous value itself, not just knowledge of
>> the type of the previous value. Strongly typed caches solve no problem here.
>>
>> So if we half-fix query but leave CQ broken I will be half-happy (ie. very
>> depressed) :)
>>
>> I'd remove these commands completely or possibly remove them just from
>> public API and keep them internal.
>>
> +1 to remove the flags from the public API. Most of them are not safe
> for applications to use, and ignoring them when they can lead to
> inconsistencies would make them useless.
>
> E.g. the whole point of SKIP_INDEX_CLEANUP is that the cache doesn't
> know when it is safe to skip the delete statement, and it relies on
> the application making a (possibly wrong) choice.
>
> IGNORE_RETURN_VALUES should be safe to use, and we actually recommend
> that applications use it right now. If query or listeners need the
> previous value, then we should load it internally, but hide it from
> the user.
>
> But removing it opens another discussion: should we replace it in the
> public API with a new method AdvancedCache.ignoreReturnValues(), or
> should we make it the default and add a method
> AdvancedCache.forceReturnPreviousValues()?

Please don't derail the thread.

>
>>
>>
>> On 06/27/2017 01:28 PM, Sanne Grinovero wrote:
>>
>>
>>
>> On 27 Jun 2017 10:13, "Radim Vansa" <rvansa at redhat.com> wrote:
>>
>> Hi,
>>
>> I am working on entry version history (again). In Como we've discussed
>> that previous values are needed for (continuous) query and reliable
>> listeners,
>>
>>
>> Index based queries also require the previous value on a write - unless we
>> can get "strongly typed caches" giving guarantees about the class to
>> represent the content of a cache to be unique.
>>
>> Essentially we only need to know the type of the previous object. It might
>> be worth having a way to load the type metadata if the previous value only.
>>
>> so I wonder what should we do with functional write-only
>> commands. These are different to commands with flags, because flags
>> (other than ignore return value) are expected to break something.
>>
>>
>> Sorry I hope to not derail the thread but let's remind that we hope to
>> evolve beyond "flags are expected to break stuff" ; we never got to it but
>> search the mailing list.
>>
>> Since flags are exposed to the user I would rather they're not allowed to
>> break things.
>> Could they be treated as hints? Ignore the flag (and warn?) if the used
>> configuration/integrations veto them.
>>
>> Alternatively, let's remove them from API. Remember "The Jokre" POC was
>> intentionally designed to explore pushing the limits on performance w/o end
>> users having to solve puzzles, such as learning details about these flags
>> and their possible side effects.
>>
>> So assuming they become either "safe" or internal, maybe you can take
>> advantage of them?
>>
>> I see
>> the available options as:
>>
>> 1) run write-only commands 'optimized', ignoring any querying and such
>> (warn user that he will break it)
>>
>> 2) run write-only without any optimization, rendering them useless
>>
>> 3) detect when querying is set up (ignoring listeners and maybe other
>> stuff that could get broken)
>>
>>
>> Might be useful for making a POC work, but I believe query will be very
>> likely to be often enabled.
>> Having an either / or switch for different features in Infinispan will make
>> it harder to use and understand, so I'd rather see work on the right design
>> as taking temporary shortcuts risks baking into stone features which we
>> later struggle to fix or maintain.
>>
> I vote for this option.
>
> Query, listeners, and other components that need the previous value
> should not just assume that the application knows better, they should
> be able to change how operations works based on their needs. Of
> course, the reverse is also true: if the application uses write-only
> commands (or IGNORE_RETURN_VALUES) for performance reasons, it should
> be possible for the user to detect why the previous values are still
> loaded.

If it were just query (static configuration), I would be okay with this 
idea. But as per listeners - besides tainting the design (event source 
should not check if there's a listener) you'd need to check *before* 
(DistributionI, CacheLoaderI) you have to call notify (cmd.perform, 
EWI). So this is a space for race conditions or weird handling (if 
there's a listener when I am about to call notify and my flags are not 
cleared, skip the notification and pretend that this code was invoked 
before the listener was registered...). Or do you have another solution 
in mind (config option to disable listeners && all features using those?).

R.

>
>> 4) remove write-only commands completely (and probably functional
>> listeners as well because these will lose their purpose)
>>
>>
>> +1 to remove "unconditional writes", at least an entry version check should
>> be applied.
>> I believe we had already pointed out this would eventually happen, pretty
>> much for the reasons you're hitting now.
>>
> IMO version checks should be done internally, we shouldn't force the
> users of the functional API to deal with versions themselves because
> we know how hard making write skew checks work is for us :)
>
> And I wouldn't go as far as to remove the functional listeners,
> instead I would change them so that read-write listeners are invoked
> on write-only operations and they force the loading of the previous
> value. I would also add a way for the regular listeners to say whether
> they need the previous value or not.
>
>> Right now I am inclined towards 4). There could be some internal use
>> (e.g. multimaps) that could use 1) which is ran without a fancy setup,
>> though, but it's asking for trouble.
>>
>>
>> I agree!
>>
>> Thanks
>>
>>
>> WDYT?
>>
>> Radim
>>
> Cheers
> Dan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team