Re: Updating a cache item without affecting it's removal from cache by LRU

[Aaron Smuts <as...@yahoo.com>]

There is no way to merely check to see if JCS contains an item.  This would have to be added to the API.  

Aaron

--- On Tue, 12/29/09, Amitay Dobo <am...@gmail.com> wrote:

> From: Amitay Dobo <am...@gmail.com>
> Subject: Re: Updating a cache item without affecting it's removal from cache  by LRU
> To: "JCS Users List" <jc...@jakarta.apache.org>
> Date: Tuesday, December 29, 2009, 5:32 AM
> It turns out my last post was wrong:
> calling put() with original
> ElementAttributes does cause the lastAccessTime to change
> anyway. What
> happened when I used the event handler, is that the cache
> item was expired
> due to maxLifeSeconds being exceeded, since the createTime
> for the
> attributes are not updates.
> 
> Amitay Dobo
> 
> So, I'm back to square one, with no known way of updating
> the contents of a
> cahed item in the cache (if it exists), without its last
> access time being
> updated. I will try to evaluate alternatives to JCS.
> 
> On Mon, Dec 28, 2009 at 4:49 PM, Amitay Dobo <am...@gmail.com>
> wrote:
> 
> > Thanks for you quick reply, Thomas.
> > I have considered using the CacheEvents mechanism for
> other reaosons, but I
> > don't think it can solve the problem I'm facing.
> Within the event handler, I
> > will still need to use (as far as i know), JCS.put().
> This will cause the
> > cache item to be mark as accessed, and will prevent it
> from being "pushed
> > out" of the cache by items which are actually used.
> > I'll try to rephrase: there are two expirations in the
> system:
> > 1) Content Expiration (application defined per item)
> > 2) Cache Expiration (controlled by JCS, might be a
> result of items pushed
> > out of cache as a result of being LRU).
> >
> > Content expiration should update the content in the
> cache (if the item is
> > still in the cache), but should *not* affect the cache
> expiration.
> >
> > However, working on the a test to confirm that using
> the events does not
> > work (since they use the regular put() method), proved
> me wrong, but not for
> > the reason i suspected. I used the following (rather
> rough) code:
> >         // event handler
> for updating the item with new data.
> >          class
> TestEventHandler implements IElementEventHandler {
> >              JCS
> m_cache;
> >
> >         
>    public TestEventHandler(JCS cache) {
> >             
>    m_cache = cache;
> >             }
> >
> >         
>    @Override
> >         
>    public void
> handleElementEvent(IElementEvent event) {
> >             
>    int eventType = event.getElementEvent();
> >             
>    System.out.println(eventType);
> >             
>    CacheElement element =
> > (CacheElement)((EventObject)event).getSource();
> >
> >             
>    if (eventType ==
> >
> IElementEventHandler.ELEMENT_EVENT_EXCEEDED_MAXLIFE_BACKGROUND)
> {
> >               
>      try {
> >               
>      
>    System.out.println("updating");
> >               
>      
>    m_cache.put(element.getKey(), "newData",
> > element.getElementAttributes());
> >
> >               
>      } catch (CacheException e) {
> >               
>          e.printStackTrace();
> >               
>      }
> >             
>    }
> >
> >             }
> >
> >         }
> >
> > And it worked!
> > I noticed that I use a different JCS.put() overload
> which accepts
> > IElementAttributes.
> > When i changed in the previously submitted code line
> from:
> > cache.put("key", "dataNew");
> > to:
> > cache.put("key", "dataNew", new ElementAttributes());
> > The item seemed to be pushed out of cache (as it
> should). However, it does
> > not seems correct, as the cache element current
> attributes should be kept
> > from the current element (along with the correct last
> access time).
> > using:
> > cache.put("key", "dataNew",
> cache.getElementAttributes("key"));
> > does not work, as it seems getElementAttributes()
> causes updating the last
> > access time.
> >
> > Since we might not use the expiration events (as we
> have our own mechanism
> > for dealing with content updates), can anyone shed
> some light on the
> > subject? Is there a way to get ElementAttributes of a
> cached item without
> > setting its access time?
> >
> >
> >
> > On Mon, Dec 28, 2009 at 12:53 PM, Thomas Vandahl
> <tv...@apache.org>
> wrote:
> >
> >> Amitay Dobo wrote:
> >> > The problem is, from what we witness, is that
> both checking if an item
> >> is
> >> > still in the cache, and by updating its data,
> JCS  mark it as accessed,
> >> and
> >> > the LRU Memory prevents it from being purged
> from the cache.
> >>
> >> You may have a look at the CacheEvent mechanisms
> available in JCS
> >> (http://jakarta.apache.org/jcs/ElementEventHandling.html).
> So you can
> >> re-insert the item when an expired event occurs,
> for example, and save
> >> unnecessary checks and background operations.
> >>
> >> > * Is there a way to peek at a cache item (or
> just check if it exists)
> >> and
> >> > update its data without the item being
> considered as accessed?
> >>
> >> I used cache groups for this.
> JCS.getGroupKeys(java.lang.String group)
> >> gives you a Set of the keys in a given group.
> >>
> >> Bye, Thomas.
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: jcs-users-help@jakarta.apache.org
> >>
> >>
> >
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org