<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 12:48 PM, Pedro Ruivo <span dir="ltr"><<a href="mailto:pedro@infinispan.org" target="_blank">pedro@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>
<br>
On 10/02/2013 12:03 AM, Sanne Grinovero wrote:<br>
> I'd love to brainstorm about the clear() operation and what it means<br>
> on Infinispan.<br>
><br>
> I'm not sure to what extent, but it seems that clear() is designed to<br>
> work in a TX, or even create an implicit transaction if needed, but<br>
> I'm not understanding how that can work.<br></div></blockquote><div><br></div>I think it's pretty straight-forward to define the semantics of operations after clear(): they should assume that every key in the cache was removed. <br>
<br>True, like Pedro mentioned, the current implementation allows subsequent operations in the same tx to see keys inserted by other txs. But I don't think fixing that would be harder than ensuring that if a tx inserts key k owned by nodes A and B, clear() from outside the tx either deletes k on A and B or doesn't delete k on either node.<br>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
><br>
> Obviously a clear() operation isn't listing all keys explicitly.<br>
<br>
</div>(offtopic) like entrySet(), keySet(), values() and iterator() when<br>
executed in a transactional context. however, I think that this<br>
operations are more difficult to handle, because they have to return<br>
consistent data...<br></blockquote><div><br></div><div>I agree, defining how entrySet() and the others should work in a tx seems harder than defining clear().<br><br>Will, I'm guessing your fix for ISPN-3560 still allows entrySet() after clear() to see entries inserted by another tx in the meantime?<br>
</div><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
> Which<br>
> implies that it's undefined on which keys it's going to operate when<br>
> it's fired.. that seems like terribly wrong in a distributed key/value<br>
> store as we can't possibly freeze the global state and somehow define<br>
> a set of keys which are going to be affected, while an explicit<br>
> enumeration is needed to acquire the needed locks.<br>
<br>
</div>you may not need to explicit acquire the lock for the affected key. you<br>
can use a global lock that is share acquired for write transactions<br>
without clear operation and exclusively acquire for transactions with<br>
clear operation (exactly what I use for Total Order). also, the clear<br>
transactions (i.e. the transactions with clear operation) can also only<br>
acquired the global lock.<br></blockquote><div><br></div><div>+1 for the global lock. It may slow things down a bit in the general case, because every tx will have to acquire it in shared mode, but it will guarantee consistency for clear().<br>
</div><div><br>It still won't help entrySet() and its brethren...<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
><br>
> It might give a nice safe feeling that, when invoking a clear()<br>
> operation in a transaction, I can still abort the transaction to make<br>
> it cancel the operation; that's the only good part I can think of: we<br>
> can cancel it.<br>
<br>
</div>yep<br></blockquote><div><br></div><div>Wouldn't it be harder to integrate it with Total Order if it didn't have a tx?<br><br></div><div>But most of all, I think we have to keep it because it's a part of the Map interface and a part of JCache's Cache interface.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
><br>
> I don't think it has anything to do with consistency though? To make<br>
> sure you're effectively involving all replicas of all entries in a<br>
> consistent way, a lock would need to be acquired on each affected key,<br>
> which again implies a need to enumerate all keys, including the<br>
> unknown keys which might be hiding in a CacheStore: it's not enough to<br>
> broadcast the clear() operation to all nodes and have them simply wipe<br>
> their local state as that's never going to deal correctly<br>
> (consistently) with in-flight transactions working on different nodes<br>
> at different times (I guess enabling Total Order could help but you'd<br>
> need to make it mandatory).<br>
><br>
<br>
</div>see the comment above about the locks... may not be the most efficient,<br>
but handles the problem.<br></blockquote><div><br></div><div>Note that we need to iterate the keys anyway, in order to fire the CacheEntryRemoved listeners. Even if we optimized it skip the iteration when there are no registered listeners, it would still have to handle the general case.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
> So let's step back a second and consider what is the use case for<br>
> clear() ? I suspect it's primarily a method needed during testing, or<br>
> maybe cleanup before a backup is restored (operations), maybe a<br>
> manually activated JMX operation to clear the cache in exceptional<br>
> cases.<br>
<br>
</div>I'm not aware of the uses cases of a clear() operation, but use it as<br>
JMX operation can be a problem in transactional caches (depending the<br>
semantic you have in mind).<br>
<br>
If it is going to clear all the caches (i.e. from all replicas/nodes),<br>
then we have to find a way to set an order with the current transactions<br>
or we will have something some nodes delivering a transaction (say tx1)<br>
before the clear() and other nodes delivering tx1 after the clear(),<br>
leading to an inconsistent state.<br>
<br>
(offtopic) I'm wondering if we have that problem in the current<br>
implementation if tx1 is only insert new keys... in that case, we have<br>
no lock to serialize an order between the clear() and tx1...<br></blockquote><div><br></div><div>I'm pretty sure we do have this problem. We definitely need to add some tests for clear concurrent with other write operations.<br>
<br></div><div>In my view, as long as we're going to expose a clear() operation in some way, it's going to be easiest to include it in a tx in transactional caches. Exposing it in some other way is not going to make it any more consistent, although prohibiting other operations in the same tx may make the code a bit simpler.<br>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
><br>
> I don't think there would ever be a need for a clear() operation to<br>
> interact with other transactions, so I'd rather make it illegal to<br>
> invoke a clear() inside a transaction, or simply ignore the<br>
> transactional scope and have an immediate and distributed effect.<br></div></blockquote><div> </div><div>We can't control whether other transactions are invoked concurrently
with clear(), so we can't make that illegal... If you mean interaction
with other operations in the same transaction, I agree that it's not
absolutely necessary to allow them, but I think most of that work has
already been done. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
</div>I think the second solution can make inconsistency data ("or simply<br>
<div>ignore the transactional scope and have an immediate and distributed<br>
</div>effect")<br></blockquote><div><br></div><div>Maybe that's the idea? Sanne, do you mean that if clear() were exposed via a different API, it wouldn't have to provide the same consistency guarantees as regular operations?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div><br>
><br>
> I'm likely missing something. What terrible consequences would this have?<br>
><br>
> Cheers,<br>
> Sanne<br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>