[infinispan-dev] [ISPN-116] Async cache store: aggregation of multiple changes on a single key

[Galder Zamarreno]

On 07/09/2009 12:11 PM, Galder Zamarreno wrote:
>
>
> On 07/07/2009 12:02 PM, Mircea Markus wrote:
>> Galder Zamarreno wrote:
>>> </snip>
>>>
>>> 1. Rather than using a queue, using a data structure similar to the
>>> one used in the data container so that when a newer value for a key
>>> already present in the queue is present, the value can be swapped (map
>>> like lookup required on the key so that O(1) is maintained) while
>>> maintaining queue-like FIFO operations required to empty it.
>> Is the FIFO order required? We apply the 'final state' when we do the
>> flush of the structure, I don't think the order of the operation is
>> relevant.
>> If this is the case, our structure might be a Map, with null values for
>> removed keys, as a convention.
>
> Hmmmm, very good point. In my mind, I was thinking that even in async
> mode, we should still apply the changes in the order they came but tbh,
> the moment you do this asynchronously, you lose the confirmation that it
> actually happens and hence, the order is probably irrelevant.

I've done overnight thinking and I might still have to maintain some 
kind of ordering due to potential clear() operation. The order in which 
clear() gets executed is pretty important (not so for purgeExpired() 
though).

I'm thinking that I'll likely keep the current mods queue, without 
storing value part on entries, and including any potential clear() 
modifications. The queue can in this way act as a hint in whc

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache