[infinispan-dev] API behaviour when using DIST

[Manik Surtani]

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