[infinispan-dev] Write-only commands

[Sanne Grinovero]

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.


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.


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

--

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

_______________________________________________
infinispan-dev mailing list
infinispan-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170627/f9a9e9c8/attachment.html