jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amitay Dobo <amit...@gmail.com>
Subject Re: Updating a cache item without affecting it's removal from cache by LRU
Date Mon, 28 Dec 2009 14:49:27 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message