[infinispan-dev] API behaviour when using DIST

[Bela Ban]

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);

?



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