Hi, persistence + Cache is one of the most common problems, in web applications. And I think "recenmtly used" algorythm is the best solution for this kind of cache. I saw a lot of cache implementations, but all of them implements "Background Cleanup" this way: Thread checks memory usage, object count in cache, size ... , locks cache for some time, removes internal references. It is not good. It costs resources and if you remove internal reference in cache it does not means you removed Object from memory, It is very possible you removed reference from "old" strong referenced object and hold internal references on "old" and unused ones. There is a better way. BTW GC collects "old" objects first on JVM I use, I don't know is it documented and standard way or is it "good luck". > > Hi, > > I think it is better to use java.lang.ref.* to solve problems related >to > > memory management. > >Not if you want to do something with the elements, like keep the >recenmtly used ones around and maybe flush the elements that aren't >being used to disk. . . . It is not a problem, you can have strong internal reference on "recenmtly used" objects. Reference returned from referenceQueue.pool() will not return null for weakReference.get(), if you use WeakReference registred with ReferenceQueue. You will not lose pooled objects, and can flush them to disk.
>The problem is that in most caches you can set the number of elements to >be held in memory, but not the size, so you have to sort of guess how >many you want to keep around. You could pass in an estimated size and >let the cache keep track of the total, but that's not really any better. >So, some sort of background cleanup might be nice. Agree, but I think it is better let GC to do its work. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
