4 Replies Latest reply on Jan 30, 2005 6:20 PM by Ben Wang

    timed expiry

    graham o'regan Newbie

      Is it likely that a timed expiry policy might be added to jboss cache? What I need to be able to do is add an item to the cache and a time-to-live, so i could have cache.add(item,3000); and it would time-out in 3000ms for example.

      I see that there is a timer task that searches for items on a fixed interval, but is the time that tha item is added recorded? Or would the insertion times have to be maintained outside of jboss cache?

        • 1. Re: timed expiry
          Thomas Cherel Novice

          Eviction policy is what you are looking for, I think.
          JBossCache provides a default LRU implementation. the "time-to-live" is not set per object you insert in the cache, but per region.
          Check eviction policy in JBossCache documentation.


          • 2. Re: timed expiry
            graham o'regan Newbie

            sorry, should have been clearer, i was asking if a time-based eviction policy would be added. I've looked thru the api and I can't see any references to the time that an FQN is added, so I suppose it would have to be maintained separately, ie listen for the creation/update of a node and log the time. Then a timertask could revise a region and look at the time that the node was added, compare it to the ttl on the node, and evict the node if necessary.

            The only problem is that this requires adding the ttl param to the put() method, and maintaining the time that that node was created. As I said before, we have coded this internally, but it depends on other libraries (namely quartz and spring) as the timer. We've extended treeCache to add the params needed and then set up quartz using spring. Do other people see the value in this, and would people be happy with those dependencies?

            The benefit of having ttl on nodes is that you can achieve the same functionality as oscache in the web tier, using filters and taglibs with timeouts which is really useful.

            • 3. Re: timed expiry
              Thomas Cherel Novice

              I think this can be all implemented as an eviction policy.

              The only thing that cannot be implemented using the eviciton policy is the ttl per node, unless you come up with a specific nming convention for the node and provide the ttl in some other ways (such as through the configuration of your eviction policy).
              Other option could be to always add a cached object in your node which will be the ttl. Your evcition policy could then look at this object to determine when the node must be evicted.


              • 4. Re: timed expiry
                Ben Wang Master

                Our design of eviction policy is not based on per-node basis. Rather it is per-region.

                Nonetheless to create *roughly* what you want to achieve, it still can be done through the current eviction policy framework.

                Couple things need to happen though:

                1. Region parameters will need to be configure dynamically. So you work with a Region still. Now it is still through configured thorugh xml. But we do have plan to add it later. See http://jira.jboss.com/jira/browse/JBCACHE?report=com.atlassian.jira.plugin.system.project:roadmap-panel for the roadmap.

                2. Write an eviction policy that ignores any node modification event and evict based on time. If you want to contribute this piece of code, let me know.