[infinispan-dev] ISPN-3557: interactions between a clear() operation and a Transaction

[William Burns]

Looking at ISPN-3557, I think that is resolved by ISPN-3560.  It was
just a bug in the commands not using the context values properly.  I
will look closer tomorrow, but I am pretty sure it is resolved (can
just add tests for PR).

I am guessing you are talking about ISPN-3558.  Either way, I agree
Cache.clear in a tx is problematic.  When I first thought of clear I
immediately think of atomicity (having the entire cache cleared at
some point), which currently this is not guaranteed.  This is due to
only acquiring locks/clearing the entries in the cache when clear is
invoked and can change before the tx is actually committed.  I was
talking with Dan briefly about it, and obviously it would be too late
to change anything for 6.0, but I think it is worth it to discuss it.

The best way I can think to make it more consistent would be when you
have a clear is that it could somehow block other insertions that it
didn't know about when invoked (maybe a new value lock) or somehow be
notified of insertions since the clear was done to know what keys to
remove additionally when it is committed.  Either way doesn't seem
appealing to me.

Not supporting clear in a tx context is appealing.  I think changing
clear to be outside of the current tx (like putForExternalRead) would
cause quite a bit of confusion instead.  To suggest either here would
be best to know what use cases we have, which you know a lot better
than I.

- Will

On Tue, Oct 1, 2013 at 4:03 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
> I'd love to brainstorm about the clear() operation and what it means
> on Infinispan.
>
> I'm not sure to what extent, but it seems that clear() is designed to
> work in a TX, or even create an implicit transaction if needed, but
> I'm not understanding how that can work.
>
> Obviously a clear() operation isn't listing all keys explicitly. Which
> implies that it's undefined on which keys it's going to operate when
> it's fired.. that seems like terribly wrong in a distributed key/value
> store as we can't possibly freeze the global state and somehow define
> a set of keys which are going to be affected, while an explicit
> enumeration is needed to acquire the needed locks.
>
> It might give a nice safe feeling that, when invoking a clear()
> operation in a transaction, I can still abort the transaction to make
> it cancel the operation; that's the only good part I can think of: we
> can cancel it.
>
> I don't think it has anything to do with consistency though? To make
> sure you're effectively involving all replicas of all entries in a
> consistent way, a lock would need to be acquired on each affected key,
> which again implies a need to enumerate all keys, including the
> unknown keys which might be hiding in a CacheStore: it's not enough to
> broadcast the clear() operation to all nodes and have them simply wipe
> their local state as that's never going to deal correctly
> (consistently) with in-flight transactions working on different nodes
> at different times (I guess enabling Total Order could help but you'd
> need to make it mandatory).
>
> So let's step back a second and consider what is the use case for
> clear() ? I suspect it's primarily a method needed during testing, or
> maybe cleanup before a backup is restored (operations), maybe a
> manually activated JMX operation to clear the cache in exceptional
> cases.
>
> I don't think there would ever be a need for a clear() operation to
> interact with other transactions, so I'd rather make it illegal to
> invoke a clear() inside a transaction, or simply ignore the
> transactional scope and have an immediate and distributed effect.
>
> I'm likely missing something. What terrible consequences would this have?
>
> Cheers,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev