Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Jim Janney Newsgroups: comp.lang.java.programmer Subject: Re: Caching with timed expiry Date: Thu, 10 May 2012 03:48:54 -0600 Organization: objurgating the centipede Lines: 63 Message-ID: References: <4fab77d3$0$6875$e4fe514c@news2.news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx04.eternal-september.org; posting-host="PnllQd880uOddfy6hsxHuQ"; logging-data="15937"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/XzzmG2F0E+ghSs5suhDr9" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:Fv3mdwx4IOwYXhFEhsABA+ejW7Q= sha1:3NuUHr4PRD68hckTg0H+J3Q+3RI= Xref: csiph.com comp.lang.java.programmer:14457 Silvio Bierman writes: > On 05/09/2012 09:14 PM, Jim Janney wrote: >> Sebastian writes: >> >>> Hello there, >>> >>> does anyone of a cache / map implementation in which entries >>> expire after a fixed time? By which I mean that after a cnfigurable >>> delay after an enzry has been caches,it is automatically removed >>> from the cache and some clean-up action (perhaps event-triggred) >>> can be taken. >>> >>> My scenario is this: A GUI client searches an LDAP server using >>> the virtual list view control. The server requires all requests >>> to be made over the same connection. So my middleware component >>> will need to check out that connection from a pool and cache it, >>> using the ASN1 cookie sent by the client as a key. >>> >>> Trouble is, if the client never signals that it won't request >>> another page (e. g. because it crashes), I need to auto-release >>> the LDAP server connection to the connection pool to prevent leakage. >>> I thought that a ready-made cache with timed expiry would come in handy. >>> If there is no such beast, any ideas for possible approaches? >>> >>> -- Sebastian >> >> Look at subclassing java.util.LinkedHashMap and overriding the >> removeEldestEntry method to check an expiration time. The removal time >> will not be precise (since it's triggered when something else is looked >> up) but it may be good enough. >> > > Actually this is not going to work since removeEldestEntry is only > called when calling put on the map and even then it is only called > once for each put, disallowing dropping multiple expired entries at > once. > I kicked LinkedHashMap around a couple of times to try and get this > working properly but gave up on it. Hmm, yes. An access-ordered LinkedHashMap may stop growing, but it will never shrink unless you explicitly remove entries. I suppose you could repeatedly add a bogus entry and then remove it again? Still not the cleanest approach. > > The simplest self-built solution is wrapping key/element pairs in > wrapper objects that also implements a doubly-linked list to represent > the queue and coupling that with a plain HashMap that maps key values > to the corresponding wrapper. > I have done this to create caches that makes elements expire if they > have been in the cache for too long or have not been retrieved for too > long. Naturally this can be done either implicitly at lookup time or > explicitly with some purgeExpiredEntries method that could be called > periodically even when not querying the cache. > > There probably also are existing cache libraries that will do this for > you if you don't mind the dependency. A separate priority queue kept in parallel with the map? -- Jim Janney