A trivial patch to the Provider to support the use of the "soft" cache option using the existing jdbm.helper.SoftCache CachePolicy implementation.
At some point, please consider adding support for cache size for softcache. You can do this by first creating an MRU of the specified size, then passing it in to the softcache constructor.
Providing an option for the loadfactor may also be desirable for tuning purposes for some users...
I didn't do this initially since the defaults that people might be using with the "normal" cache are not going to be appropriate for the "soft" cache based on the javadoc on SoftCache. I thought that it would be better to offer less customization with less suprise.
I'm happy to revisit this. Would you be more inclined to see the same CACHE_SIZE property effect the both kinds of caches and also to add a load factor to them at the same time?
hmmm - good point...
and we ignore the jdbm.cache.size parameter?
Regardless, these are little details that can be worried about later after we know for sure that this thing is working the way we want it to. Just having softcache available is a huge step forward (hard to believe it's been sitting in the code base all this time).
Alex - any idea why that has been sitting there unused?
FYI - I am running with the SoftCache now. I have an equals() implementation in my app that tests first on object reference equality and if that fails tests on the recid for the objects and complains if the objects have the same recid. I have been seeing little complaints all over, but using the SoftCache has nicely gotten rid of them for me. Needless to say, I will leave in my complaint detector while we give this a whirl.
With respect to the SoftCache parameters, I will borrow the language from the SoftCache class and expose parameters for the L1 and L2 caches.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.