Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #14427 > unrolled thread

Caching with timed expiry

Started bySebastian <sebastian@undisclosed.invalid>
First post2012-05-08 23:48 +0200
Last post2012-05-09 13:09 -0700
Articles 11 — 8 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  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

#14427 — Caching with timed expiry

FromSebastian <sebastian@undisclosed.invalid>
Date2012-05-08 23:48 +0200
SubjectCaching 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]


#14452

FromJim Janney <jjanney@shell.xmission.com>
Date2012-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]


#14456

FromSilvio Bierman <silvio@moc.com>
Date2012-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]


#14457

FromJim Janney <jjanney@shell.xmission.com>
Date2012-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]


#14459

FromSilvio Bierman <silvio@moc.com>
Date2012-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]


#14458

FromArved Sandstrom <asandstrom3minus1@eastlink.ca>
Date2012-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]


#14502

FromSebastian <sebastian@undisclosed.invalid>
Date2012-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]


#14455

FromRoedy Green <see_website@mindprod.com.invalid>
Date2012-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]


#14506

FromRobert Klemme <shortcutter@googlemail.com>
Date2012-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]


#14698

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-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]


#14510

FromPaul Cager <paul.cager@googlemail.com>
Date2012-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