The indexed disk cache stores the index in memory. A disk miss requires no IO.
Aaron --- On Tue, 1/12/10, game...@nationwide.com <game...@nationwide.com> wrote: > From: game...@nationwide.com <game...@nationwide.com> > Subject: Re: question on isSpool=true > To: "JCS Users List" <jcs-users@jakarta.apache.org> > Date: Tuesday, January 12, 2010, 10:47 AM > Thank you! > > Does checking disk cache for presence of an element involve > a disk I/O? Or the disk cache map (index) remains in memory > at all times? > > Thank you > Val > > > ----- Original Message ----- > From: Aaron Smuts [asm...@yahoo.com] > Sent: 01/12/2010 10:05 AM PST > To: JCS Users List <jcs-users@jakarta.apache.org> > Subject: Re: question on isSpool=true > > > > JCS will look for items in the various auxiliaries in > configuration order. If you specify a remote cache in > the list before a disk cache, then JCS will look in the > remote cache before the disk cache. Before JCS looks > in disk, lateral, or remote auxiliaries, it will first check > the memory cache. > > So, in your case, if the item is not in memory JCS will > look on disk. If it find the item it will retrieve it, > put it to the memory cache (if the diskUsagePattern is not > UPDATE and the memory size is not 0). After the put > call, the item will be returned to the client. The put > functions as any other. If the memory store is full, > the least recently used item in memory (assuming that you > are using the LRU memory cache) will be spooled to > disk. Items are queued and asynchronously put to all > auxiliaries. So, no you don't have to wait for the > next item to be written to disk. You only have to wait > for it to be queue. > > Aaron > > --- On Tue, 1/12/10, game...@nationwide.com > <game...@nationwide.com> > wrote: > > > From: game...@nationwide.com > <game...@nationwide.com> > > Subject: Re: question on isSpool=true > > To: "JCS Users List" <jcs-users@jakarta.apache.org> > > Date: Tuesday, January 12, 2010, 9:19 AM > > thank you. > > > > What about part 3 of the question? About disk writing > being > > synchronous/blocking. > > > > Thanks > > Val > > > > > > ----- Original Message ----- > > From: Aaron Smuts [asm...@yahoo.com] > > Sent: 01/11/2010 07:01 PM PST > > To: JCS Users List <jcs-users@jakarta.apache.org> > > Subject: Re: question on isSpool=true > > > > > > > > The IsSpool, IsLateral, and IsRemote specify whether > an > > item will be allowed to go to a disk, lateral, or > remote > > auxiliary respectively. If there is no disk > auxiliary > > configured, for instance, the IsSpool value is > > irrelevant. By default all three are true. If > > you configure a disk auxiliary, and if IsSpool is true > for > > the item, it will be spooled to disk per the disk > usage > > pattern. > > > > The default disk usage pattern sends items to disk > only > > when the memory store is full. In contrast, the > UPDATE > > disk usage pattern will send all items to disk > regardless of > > whether or not there is room in memory. > > > > Your description is reversed. If you are using the > > LRU memory cache and if you have a size limit on the > memory > > of 100, the 1st item will be sent to disk when the > 101st is > > added, assuming that they were never accessed. If > the > > 1st item was accessed after the 2nd was inserted or > > accessed, then the 2nd will be spooled. The least > > recently used item will be spooled. > > > > Aaron > > > > --- On Mon, 12/28/09, game...@nationwide.com > > <game...@nationwide.com> > > wrote: > > > > > From: game...@nationwide.com > > <game...@nationwide.com> > > > Subject: question on isSpool=true > > > To: "JCS Users List" <jcs-users@jakarta.apache.org> > > > Date: Monday, December 28, 2009, 8:46 AM > > > Here is a typical cache region > > > configuration for us: > > > jcs.region.lookupCache=DC2 > > > > > > jcs.region.lookupCache.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes > > > > jcs.region.lookupCache.cacheattributes.MaxObjects=100 > > > > > > jcs.region.lookupCache.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache > > > > > > jcs.region.lookupCache.elementattributes=org.apache.jcs.engine.ElementAttributes > > > > > > jcs.region.lookupCache.elementattributes.IsEternal=false > > > > > > jcs.region.lookupCache.elementattributes.MaxLifeSeconds=500000 > > > > jcs.region.lookupCache.elementattributes.IdleTime=1 > > > > jcs.region.lookupCache.elementattributes.IsSpool=true > > > > > > jcs.region.lookupCache.elementattributes.IsRemote=true > > > > > > jcs.region.lookupCache.elementattributes.IsLateral=true > > > > > > 1. Can you confirm I am reading this correctly? > > > a. Some cached data (anything over 100 objects > but > > within > > > the > > > MaxLifeSeconds) will spill to disk, due to > IsSpool = > > true > > > b. Although IsRemote and IsLateral are both set > to > > true, it > > > really does > > > not mean that cache will be remote or > synchronized > > between > > > multiple > > > servers since none of these aspects are > configured > > > > > > 2. Can you clarify the implications of cached > data > > > "spilling" over to > > > disk? Once I have 101st object (in the example > above) > > that > > > cache > > > determines is going to be cached, does it mean > > that, > > > when I as a user of > > > this cache region do "getElement(101)", the > caching > > > framework will: > > > a. Determine that 101 is not in the cache > > > b. Send 1 LRUed object out to the disk cache > (spill > > > "cached" data to disk) > > > c. Cache in memory element 101 > > > > > > 3. If the above sequence of events is correct, > can I > > > presume that 2a, 2b, > > > 2c will be executed synchronously (i.e. the call > to > > > getElement will be > > > blocking until all a, b, and c operations are > > complete)? > > > asynchronously? > > > Combination of thereof? > > > > > > Thank you > > > Val > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org > > For additional commands, e-mail: jcs-users-h...@jakarta.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org > > For additional commands, e-mail: jcs-users-h...@jakarta.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org > For additional commands, e-mail: jcs-users-h...@jakarta.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org > For additional commands, e-mail: jcs-users-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org For additional commands, e-mail: jcs-users-h...@jakarta.apache.org
