[infinispan-dev] API behaviour when using DIST

[Manik Surtani]

On 24 Apr 2009, at 06:52, Bela Ban wrote:

> Whatever you do, I think quick'n'dirty fire&forget calls are  
> important: a user might want to push data into the grid at a very  
> high rate and does not care about return values (for now).
>
> Maybe an additional API ?
>
> void putAsync(key, value);
>
>
> Or a batch API:
>
> void putBatch(Map<K,V> data);

Well, putAll(Map<K, V> data) behaves like this since it returns void...


>
>
> ?
>
>
>
> Manik Surtani wrote:
>> Thinking about this a bit more (and implementing tests, etc for  
>> this) I think even for the async case we need to do the remote get  
>> first (and as a side-effect this would provide reliable return  
>> values).  The reason is that not doing this causes txs to behave  
>> very weird and would need a lot of hacks to behave cleanly without  
>> doing the eager get.
>>
>> Take this example (assuming dist-async)
>>
>> 1.  tx.begin
>> 2.  putIfAbsent(k) // k exists elsewhere
>> 3.  get(k) // this will return the OLD val of k, since the tx hasnt  
>> completed and the owners haven't seen the WriteCommand in 2 yet!
>>
>> We could hack this to make a record of commands that will be  
>> executed later, but in the case of conditional writes (like  
>> putIfAbsent) we dont know if they will succeed.  So we could do a  
>> get first as well, but in this case then we may as well stick with  
>> a get-before-write approach and thereby provide reliable retvals.
>>
>> The actual commit would still be 1-phase and async though.
>>
>> WDYT?
>>
>> Also, for consistency, I suggest the same for non-tx-writes.  This  
>> then serves the added benefit of removing the weird unsafe flag,  
>> etc.  Ok, so it means doing a remote get before a put, but the cost  
>> of this is mitigated because a) it is unicast  to a small set of  
>> servers b) the RPC call returns as soon as we get the first valid  
>> response and c) with MVCC, the get is very quick - no locking  
>> needed on the remote end.
>>
>> Comments?
>>
>>
>> On 21 Apr 2009, at 18:24, Manik Surtani wrote:
>>
>>>
>>> On 21 Apr 2009, at 18:18, Mircea Markus wrote:
>>>
>>>> Manik Surtani wrote:
>>>>>
>>>>> On 21 Apr 2009, at 18:01, Mircea Markus wrote:
>>>>>
>>>>>> yes, indeed. that's what cache.retrieve("key1", "key2",  
>>>>>> "keyn"...); would do, fetch all the remote values at once  
>>>>>> (multiple keys mapped to one node will result in one aggregated  
>>>>>> get).
>>>>>>> Sounds pretty clunky though ...
>>>>>> Might be. I think it is easy to grasp though, and can have  
>>>>>> significant benefits for clients that know all the key set they  
>>>>>> will manipulate in one session.
>>>>>
>>>>> But the keys retrieved could still be wiped out.
>>>>>
>>>>> 1.  start tx
>>>>> 2.  retrieve(k1, k2, k3)
>>>>> 3.  // go make coffee; other processes changing stuff, which  
>>>>> removes keys from the L1, negating the effect of step 2
>>>> Isn't that exactly what happens now with read mvcc entries being  
>>>> held in context? This won't break neither read_committed nor  
>>>> repetable_read.
>>>
>>> Not quite.  The return value is calculated atomically when the  
>>> command is performed, even though the old value is cached in  
>>> context.  E.g.,  locally,
>>>
>>> 1.  tx.begin
>>> 2.  read K
>>> 3.  // go make coffee
>>> 4.  replace K.  This command is atomic and the retval is extracted  
>>> from the datacontainer as this command is perform()'ed.  So what  
>>> this invocation returns is accurate regardless of interleaving  
>>> writes between step 2 & 4
>>> 5. ...
>>>
>>>>> 4.  replace(k1, v1) // will return incorrect retval.  Or will  
>>>>> need to do a remote get again at this point
>>>>> 5.  end tx
>>>>>
>>>>> -- 
>>>>> Manik Surtani
>>>>> manik at jboss.org
>>>>> Lead, Infinispan
>>>>> Lead, JBoss Cache
>>>>> http://www.infinispan.org
>>>>> http://www.jbosscache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> -- 
>>> Manik Surtani
>>> manik at jboss.org
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> -- 
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> -- 
> Bela Ban
> Lead JGroups / Clustering Team
> JBoss - a division of Red Hat
>

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org