Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #14427 > unrolled thread
| Started by | Sebastian <sebastian@undisclosed.invalid> |
|---|---|
| First post | 2012-05-08 23:48 +0200 |
| Last post | 2012-05-09 13:09 -0700 |
| Articles | 11 — 8 participants |
Back to article view | Back to comp.lang.java.programmer
Caching with timed expiry Sebastian <sebastian@undisclosed.invalid> - 2012-05-08 23:48 +0200
Re: Caching with timed expiry Jim Janney <jjanney@shell.xmission.com> - 2012-05-09 13:14 -0600
Re: Caching with timed expiry Silvio Bierman <silvio@moc.com> - 2012-05-10 10:09 +0200
Re: Caching with timed expiry Jim Janney <jjanney@shell.xmission.com> - 2012-05-10 03:48 -0600
Re: Caching with timed expiry Silvio Bierman <silvio@moc.com> - 2012-05-10 12:56 +0200
Re: Caching with timed expiry Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-10 06:57 -0300
Re: Caching with timed expiry Sebastian <sebastian@undisclosed.invalid> - 2012-05-13 23:05 +0200
Re: Caching with timed expiry Roedy Green <see_website@mindprod.com.invalid> - 2012-05-09 14:43 -0700
Re: Caching with timed expiry Robert Klemme <shortcutter@googlemail.com> - 2012-05-14 23:47 +0200
Re: Caching with timed expiry Arne Vajhøj <arne@vajhoej.dk> - 2012-05-20 22:18 -0400
Re: Caching with timed expiry Paul Cager <paul.cager@googlemail.com> - 2012-05-09 13:09 -0700
| From | Sebastian <sebastian@undisclosed.invalid> |
|---|---|
| Date | 2012-05-08 23:48 +0200 |
| Subject | Caching with timed expiry |
| Message-ID | <joc4c0$2hm$1@news.albasani.net> |
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
[toc] | [next] | [standalone]
| From | Jim Janney <jjanney@shell.xmission.com> |
|---|---|
| Date | 2012-05-09 13:14 -0600 |
| Message-ID | <ydn3979kvz7.fsf@shell.xmission.com> |
| In reply to | #14427 |
Sebastian <sebastian@undisclosed.invalid> 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. -- Jim Janney
[toc] | [prev] | [next] | [standalone]
| From | Silvio Bierman <silvio@moc.com> |
|---|---|
| Date | 2012-05-10 10:09 +0200 |
| Message-ID | <4fab77d3$0$6875$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #14452 |
On 05/09/2012 09:14 PM, Jim Janney wrote: > Sebastian<sebastian@undisclosed.invalid> 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. 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. Silvio
[toc] | [prev] | [next] | [standalone]
| From | Jim Janney <jjanney@shell.xmission.com> |
|---|---|
| Date | 2012-05-10 03:48 -0600 |
| Message-ID | <ydny5p0jri1.fsf@shell.xmission.com> |
| In reply to | #14456 |
Silvio Bierman <silvio@moc.com> writes: > On 05/09/2012 09:14 PM, Jim Janney wrote: >> Sebastian<sebastian@undisclosed.invalid> 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
[toc] | [prev] | [next] | [standalone]
| From | Silvio Bierman <silvio@moc.com> |
|---|---|
| Date | 2012-05-10 12:56 +0200 |
| Message-ID | <4fab9efa$0$6969$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #14457 |
On 05/10/2012 11:48 AM, Jim Janney wrote:
>
> A separate priority queue kept in parallel with the map?
>
Yep, that is what I meant. If you wrap both in the cache object they are
easy to keep synchronized.
I suggested implementing the priority queue manually and put queue nodes
as values in the HashMap to prevent O(n) operations on the queue(s).
For the situation where I needed to handle both cache presence timeouts
AND cache lookup timeouts it looked something like:
public class MyCache<K,V>
{
private class Node
{
K key;
V value;
Node previousAddition;
Node nextAddition;
long additionTime;
Node previousAccess;
Node nextAccess;
long accessTime;
}
private HashMap<K,Node> lookup = new HashMap<K,Node>();
private Node accessHead;
private Node accessTail;
private Node additionHead;
private Node additionTail;
//...
}
Only an approximation from the top of my mind, the actual code is Scala.
The operations are trivial to implement.
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2012-05-10 06:57 -0300 |
| Message-ID | <viMqr.3102$TC4.1725@newsfe14.iad> |
| In reply to | #14456 |
On 12-05-10 05:09 AM, Silvio Bierman wrote: > On 05/09/2012 09:14 PM, Jim Janney wrote: >> Sebastian<sebastian@undisclosed.invalid> 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. > > 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. Google Guava with its CacheBuilder, or ehcache, for example. > Silvio AHS -- Never interrupt your enemy when he is making a mistake. --Napoleon
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <sebastian@undisclosed.invalid> |
|---|---|
| Date | 2012-05-13 23:05 +0200 |
| Message-ID | <jop7nc$lsb$1@news.albasani.net> |
| In reply to | #14458 |
Thank you everyone for your help. Google Guava does
indeed do all I need:
Cache<ASN1Octet, LDAPConnection> connectionCache =
CacheBuilder.newBuilder()
.expireAfterAccess(2, TimeUnit.MINUTES)
.removalListener(MY_LISTENER)
.build();
-- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | Roedy Green <see_website@mindprod.com.invalid> |
|---|---|
| Date | 2012-05-09 14:43 -0700 |
| Message-ID | <g7plq792jto36o32dqc5bi3k9gv2p94tt6@4ax.com> |
| In reply to | #14427 |
On Tue, 08 May 2012 23:48:48 +0200, Sebastian <sebastian@undisclosed.invalid> wrote, quoted or indirectly quoted someone who said : >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 You might want to look into weak links. http://mindprod.com/jgloss/weak.html See -- Roedy Green Canadian Mind Products http://mindprod.com Programmers love to create simplified replacements for HTML. They forget that the simplest language is the one you already know. They also forget that their simple little markup language will bit by bit become even more convoluted and complicated than HTML because of the unplanned way it grows. .
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2012-05-14 23:47 +0200 |
| Message-ID | <a1dcrdF70bU1@mid.individual.net> |
| In reply to | #14455 |
On 09.05.2012 23:43, Roedy Green wrote: > On Tue, 08 May 2012 23:48:48 +0200, Sebastian > <sebastian@undisclosed.invalid> wrote, quoted or indirectly quoted > someone who said : >> 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. > You might want to look into weak links. > http://mindprod.com/jgloss/weak.html That does not give you control of the timing. In theory a SoftReference might be better because GC is more reluctant to clear it. But it's not entirely clear whether they actually behave differently in practice and you still do not get control of timing. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-05-20 22:18 -0400 |
| Message-ID | <4fb9a5f3$0$289$14726298@news.sunsite.dk> |
| In reply to | #14455 |
On 5/9/2012 5:43 PM, Roedy Green wrote: > On Tue, 08 May 2012 23:48:48 +0200, Sebastian > <sebastian@undisclosed.invalid> wrote, quoted or indirectly quoted > someone who said : >> 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. > You might want to look into weak links. Why? They do not provide the functionality requested. Is "in which entries expire after a fixed time" a difficult requirements to understand? Arne
[toc] | [prev] | [next] | [standalone]
| From | Paul Cager <paul.cager@googlemail.com> |
|---|---|
| Date | 2012-05-09 13:09 -0700 |
| Message-ID | <7aaa0519-5e9c-4e5e-955c-0d534bc90a4b@v2g2000vbx.googlegroups.com> |
| In reply to | #14427 |
On May 8, 10:48 pm, Sebastian <sebast...@undisclosed.invalid> wrote: > Hello there, > > does anyone of a cache / map implementation in which entries > expire after a fixed time? Have a look at Guava http://code.google.com/p/guava-libraries/ and http://code.google.com/p/guava-libraries/wiki/CachesExplained
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.java.programmer
csiph-web