RE: [coldbox:3121] Re: CacheManager: Cannot find LastAccessTimeout key in struct

I think the bigger question here is whether or not eternal cache objects
go to heaven when they die.
Frankly, I'm not so sure Saint Peter would let my userService in the
pearly gates. :stuck_out_tongue:

Seriously though, answer me this question: What benefit do you receive
from using the cache manager as opposed to the application storage plug
in?
In my opinion, the cache manager is basically the same as the app
storage plug in, but with a built-in ability to purge itself. If you
don't want your objects to ever be purged, why would you choose the
system whose only benefit was a purging functionality you weren't going
to use?

To be fair, the only other thing cache manager gives you is reporting,
but I really only care about that for my transient cached objects.

~Brad

LOL,

Seriously though, answer me this question: What benefit do you receive
from using the cache manager as opposed to the application storage plug
in?
Well, you cannot autowire from the application scope. You can autowire from the cache. This is a big one.

Other caches like ehCache have the concept of eternal objects that do not get expired also, that is where the idea came and I had forgotten about that. (too much now).

One of the biggest impacts would be the autwiring, since you can basically wire anything up from the cache.

I am even thinking that maybe the cache manager can have two regions,
one for eternal objects and one for non-eternal objects. Then the
reaping procedure, evictions and size counts will all be based on non-
eternal objects.

However, I think that having the capabilities of eternal objects is
very beneficial, as you can cache with confidence, but of course, you
can also cache until you run out of memory, but you can do that in ANY
cache that allows eternal objects.

The big plus about this, is the autowiring, you can easily wire up
objects from the cache.

Thoughts?