Mark you might consider using a LRU (least recently used) cache for caching a finite amount of objects.  Consider that you want ten items in your cache.  You have an array that is 10 items long.  The position in the array denotes how recently used the object is.  New objects get pre-appended to the array - which will automatically knock off the 10th (now 11th) item.  Objects that already exist in the cache - say abcSerivce which is in the 7th position -- will be moved from 7 to 1.  Items after the tenth position are deleted off the array.

I used LRU type cache in LylaCaptcha however instead of having to maintain items for infinite amount of time -- I just needed to make sure that items were around for a finite amount of time.  So what I did was have an array with a length of two in which there was a struct in each.  New items were always appended to the first array's struct.   On init of this array, I set a tick count.  Whenever a new item is appended to the array - it checks if the current tick count is over a certain threshold (say 120 seconds).  If that is that case, it bumps the 1 part of the array to 2 and creates a new blank struct in the first position.  The third part of the array is just deleted because it was expired.  It's sorta like a poor man's LRU (although really fast because you're not scanning each struct element just checking if the time is over the threshold and bumping it down a slot and deleting an array position). 

Unless you are managing a ton of objects in the cache - moving things around the array shouldn't be a problem  especially if you don't scan for garabage collection each request.  You might consider only scanning for expired objects on every tenth request to cache -- it's not necessary that things expire exactly on time -- they just need to expire sometime "soon", but accurately.  You might consider that when new objects are added to the cache -- things are bumped around, but the clean only occurs when asking for sometime that already exists (and only every tenth time or something).

Ok, done rambling late at midnight!

HTH and Best,
.Peter


From: "Mark Mandel" <[EMAIL PROTECTED]>
Sent: Monday, May 08, 2006 7:13 PM
To: [email protected]
Subject: Re: [CFCDev] Deploying Java Code with your ColdFusion app


Roland -

I'm writing this for a generic lib (Transfer fo be exact), so it could
be instantiated in the application scope anywhere, it could be a
singleton in ColdSpring, it could be instance data to another Factory
CFC somewhere etc etc. So writing a scheduled task unfortunatley is
out of the question (I wish it wasn't!).

The case came out of a having a business need to be able to granularly
control how objects were cached in the system. So I'm having to build
controls for that. (I.e. I got told if we were going to use Transfer,
we would have to have this functionality)

The expired slots idea is a good one, and I will probably end up
looking into that as well.

I'm going to have to do some synchronous cleanup as well, as I can't
get Java objects to talk to CF instances of CFCs, but I'm trying to
minimise that.

I would also like to be able to implement some smart caching - i.e. if
you have set a max number of objects to 10, and you have 12, the cache
should keep the most accessed objects around, rather than just
removing 2 at random.

This could be slightly expensive, depending on how you want to do it,
so it would be nice to do it in it's own Thread.

But thanks for your thoughts, this is an interesting conversation.

Mark

On 5/9/06, Roland Collins <[EMAIL PROTECTED]> wrote:
> What scope wouldn't you be able to access with a scheduled task? A
> scheduled task should be able to access any scope in the application.
>
> You could also consider reusing expired slots instead of full-on garbage
> collection. In other words - when allocating a new object, just search
> through your cache and allocate the new object in the first expired slot
> that you find, or create a new one if necessary. It creates kind of a
> "lazy" cache that way - you may have expired objects in there, but if
> there's no side-effect to having them, then it doesn't really matter. That
> alleviates the threading issue altogether. And IMO, if you can avoid having
> to do it asynchronously, it'll save you a lot of pain down the road.
>
> Roland
>

--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
ICQ: 3094740


----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]



Reply via email to