[infinispan-dev] FIFO ordering...

Tue Oct 20 17:29:55 EDT 2009

I didn't try using FIFODataContainer since it's set via the eviction
tag.  I didn't know you could turn off the wakeUpInterval to turn off
eviction.

I did just try it (FIFODataContainer) with our code and it worked just
fine since we just use the keyset().  

One other thing we had to modify was add some methods to the
AdvancedCache interface.

   K getNextKey();
   V getNext();
   V getNext(long timeout);
   V take();
   V take(long timeout);

The main one we need is getNextKey().  For this to work properly we need
to get the next unlocked key in the cache.  

We use FIFO for workflow so a transaction will start and get the next
key.  It will then process the data and commit the transaction.  Other
threads can do the same when there is work so we need to make sure the
next key is the next unlocked key.  A rollback of the transaction should
put the key back in the queue.

The only way I could figure out how to check if a key was locked was via
the LockManager.  The CacheDelegate didn't have access to is so I added
it.

Anyhow, point being it looks like we need to extend the API and some
core classes a little to get this to work.  What's the best way to
accomplish this since modifying the core interface and core classes is
probably not going to fly?

Bryan

-----Original Message-----
From: infinispan-dev-bounces at lists.jboss.org
[mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Manik
Surtani
Sent: Tuesday, October 20, 2009 11:26 AM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] FIFO ordering...

The problem is to maintain additional ordering, which can be expensive  
(more pointers, CAS, etc for every insertion or deletion).  If there  
is no such need for a generic solution, then using an iterator on the  
map while configuring the cache to use FIFO eviction will give you the  
same effect.

On 20 Oct 2009, at 19:08, Bryan Grunow wrote:

> My solution is per node at this point.  For what I need that is enough
> but I don't feel it's a complete solution.  Other grid applications  
> I've
> used like this support it per node as well but distribute the call  
> once
> the initial cache node is emptied.  This can lead to starvation but  
> it's
> easy.  I can't say I like it.  I would think we could come up with
> something better if needed.
>
> Yes, I looked at FIFODataContainer.  In fact my initial implementation
> was to create a new data container that kept a queue and returned an
> ordered keyset().
>
> I'd like to add queue support regardless of DataContainer but there
> doesn't seem to be a way at that low of a level to hook into things
> across data container impl.
>
> Bryan
>
> -----Original Message-----
> From: infinispan-dev-bounces at lists.jboss.org
> [mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Manik
> Surtani
> Sent: Tuesday, October 20, 2009 10:52 AM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] FIFO ordering...
>
>
> On 20 Oct 2009, at 17:54, Bryan Grunow wrote:
>
>> I posted JIRA issue https://jira.jboss.org/jira/browse/ISPN-132 a
>> while ago and I'm wondering if it's on the roadmap anywhere?
>>
>> I've worked on this internally and have a working solution but I'd
>> like to know it's coming soon or not.  If not I will continue
>> working on it but I need some guidance on the design to make sure it
>> fits properly into Infifispan.
>
> Hmm, almost as a side effect of an ordered data container (needed for
> eviction), you would have a FIFO queue, albeit one that just gives you
> a view of state local to the node.  The DataContainer impl used when
> you enable FIFO eviction is the FIFODataContainer, and calling
> Cache.keySet().iterator() would iterate over the FIFODataContainer.
>
> Does your solution actually provide a global view in a FIFO manner?
> And if so, how does it provide FIFO guarantees over concurrent
> insertions made on different cluster nodes?  Or is this a non-strict
> FIFO impl?
>
> Cheers
> --
> 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
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain  
> confidential information, privileged material (including material  
> protected by the solicitor-client or other applicable privileges),  
> or constitute non-public information. Any use of this information by  
> anyone other than the intended recipient is prohibited. If you have  
> received this transmission in error, please immediately reply to the  
> sender and delete this information from your system. Use,  
> dissemination, distribution, or reproduction of this transmission by  
> unintended recipients is not authorized and may be unlawful.
>
> _______________________________________________
> 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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.