It has been several years since I was involved in that cache code, and that was with JDBM before there was a code / project fork. I assume that we are talking about the original JDBM code line.  

The concept of a weak reference cache is that hard references, e.g., in a fixed size ring buffer, pin some number of objects.  Once those objects are evicted from the ring buffer they are either ignored (if dirty) or evicted to the disk. The weak reference cache acts as a canonicalizing mapping so you always get the right view of the object.  This generally involves having a per connection cache if you support multiple connections.  

If the record evicted from the ring buffer is clean, then it remains weakly reachable and can still be retrieved from the cache.  If any hard reference exists to that record, then it will be pinned into the cache.  The ring buffers is a handy supply of hard references to recently used records.

Weak references that are swept by gc are reported to a reference queue object.  The weak reference has already been cleared, but he entry for the record key still needs to be removed from the cache since it is now associated with a weak reference that does not point anywhere.

I do not remember the JDBM implementation In detail.  The bigdata project on source forge has several implementations of this pattern that I wrote. Infinispan also has some caches with this pattern - we collaborated on lock amortization approaches.


On Jan 21, 2014, at 1:42 PM, "Dan Gravell" <> wrote:

As per I tend to use SoftReferences for caches, but understand this might not be the best way to work with the JDBM cache.

Can you explain a little more what you mean by "The capacity of the hard reference cache fronting for the weak reference cache then sets the retention capacity for the objects"? I notice the Entry inner class for WeakCache doesn't store the values in a hard reference.

SoftCache not garbage collecting

Sent from because you indicated interest in

To unsubscribe from further messages, please visit