Hi all, Thank you all for your thoughtful responses. :-) Alex's explanation of how objects are faulted in / out on demand hit the nail on the head, and it sounds like the architecture will scale out well from what I can gather from Taylor's explanation as well. Although I am not in need of any kind of caching solution now, I had previously investigated using Tangosol's Coherence product and was wondering if the architecture was in any way similar to their partitioned cache architecture http://wiki.tangosol.com/display/COH33UG/Partitioned+Cache+Service where the addition of more VMs enabled more data / objects to be held in the entire cache on the network, while also providing failover / failback services.
Thanks so much, Jim ---------- Forwarded message ---------- From: Geert Bevin <[EMAIL PROTECTED]> Date: Sep 8, 2007 2:36 AM Subject: Re: [tc-dev] Please elaborate on distributed architecture of TC Cache To: [email protected] Hi Alex, nice overview, I do think though that is the latest version of the EhCache evictor, the keys are not necessarily on all nodes. If I understand the new implementation correctly, during the eviction process they ask each node to claim ownership of the current local entries and only perform eviction on those. Similarly, when the global evictor is run, this only happens on the entries that are not claimed by any of the currently active nodes. So, apart from eviction, the keys and the timestamp-related optimizations are stored in regular HashMaps, which are optimized by Terracotta in the regular fashion. So in summary, I do think that the current EhCache implementation keeps as much data local as possible if the striping and partitioning is correctly done on an application level, as you describe in your response. Take care, Geert On 07 Sep 2007, at 21:33, Alex Miller wrote: > Hi Jim, I'm not an expert on any of the caching stuff but I think I > can answer from general principles and Geert can tell you why I'm > wrong... :) > > Terracotta ultimately stores the distributed heap on disk, so it > can manage a fairly large heap, certainly much much larger than > your typical JVM in-memory heap. Each client will have some > portion of the distributed heap in JVM heap, based on their usage > pattern. Objects are faulted in and out of each VM as necessary, > so no client (or server) must hold all of the cache values in memory. > > I believe that most of the Terracotta-enabled caches (TC Cache, > ehcache, etc) do require that cache *keys* are all in memory, so > there are some constraints there, although keys are generally a > smallish portion of the cache. > > Additionally, I do not believe there is a way to intentionally > stripe/partition/shard the data in any of the Terracotta-enabled > caches. Rather, the in-memory portion is based on usage and you > can somewhat drive that by applying partitioning above the cache > level. For instance by using some kind of load balancing or > partitioning scheme to force requests A-L to Server 1 and requests > M-Z to Server 2. In this setup, the servers would naturally > partition the data based on usage. The nice thing would be that > both servers could serve all of the cache for failover - it's just > that the data isn't in client memory in both. > > Alex > > > ----- Original Message ----- > From: "Jim Bethancourt" <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, September 7, 2007 2:21:32 PM (GMT-0600) America/Chicago > Subject: Re: [tc-dev] Please elaborate on distributed architecture > of TC Cache > > I apologize for not mentioning that I meant RAID 5 configuration, > where each VM has a piece of the cache, and another VM has a backup > of the data. > > Thanks, > Jim > > On 9/7/07, Jim Bethancourt <[EMAIL PROTECTED]> wrote: > > Hi Geert, > Could you possibly elaborate on the distributed architecture of > the TC Cache? I've come across a number of distributed caches > before, but they only attempt to maintain replicas of the same data > in each of the distributed caches and do not scale in the amount of > data you can have in the entire cache. Does the TC Cache work in > this way, or does it work like more of a RAID style software cache, > where the more VMs you have, the more data you can hold in the > cache federation? > > Thanks, > Jim > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
