Because it lets you adjust the degree of retention simply by changing the
MRU size. But the point is the same
way, the weak/soft cache entries are inside of the CacheRecordManager CacheEntry
objects. Since noone
holding onto the CacheEntry objects, the cache is not doing what we
I've never understood why one would want a
weakreferencecache... I always use softreference myself...
Using Tomcat but need to do more? Need to support web services, security? Get
stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
_______________________________________________ Jdbm-developer mailing list
CacheRecordManager inserts CacheEntry objects into the
weak value cache. Those objects have attributes
recid, serializer, dirty flag and a hard reference to the object.
The weak value cache will clear
these entries as soon as they are no
longer strongly reachable. Since the application does not hold
CacheEntry objects itself, but only the object reference,
it seems that the CacheEntry entries in the weak value
will be swept by the garbage collector and removed from the weak value
cache shortly after they fall off of
the internal hard
reference MRU. That is, it does not look like the weak value cache
is serving any purpose.
Behalf Of Kevin Day
Sent: Monday, April 17, 2006 10:46
To: JDBM Developer listserv
Subject: re: [Jdbm-developer]
Soft/Weak cache question - it seems like we have a hole in the ca
che commit behavior.
think this is an issue. Under the current code, if an object
evicts from the cache, and the object has been marked as updated,
then it's content gets written to the page and marked dirty.
In the case of the weak cache, it is fronted by an MRU cache, so
the cache eviction technically happens when the object is evicted
from the MRU (this technically results in an earlier page write
than is actually needed, but there's no way to capture a weak
reference eviction immediately before it occurs, so a compromise
I am looking over the WeakCache class and I am wondering
if the following scenario is possible: The WeakCache has a large
number of entries, greater than the size of the internal MRU cache
when the transaction commits. This could happenif the
application was maintaining its own hard references to those
runtime objects, e.g., in some caches or temporary data
structures. During the commit the CacheRecordManager will
ask for an enumeration of the objects in the cache. The
enumeration provided will visit the members of the internal MRU,
not those in the weak value cache. Since the weak cache has
more objects that can fit on the internal MRU cache, some dirty
objects will not be reported to the cache record manager and the
transaction will not commit all changes.
I think that what
we need to do is place the dirty objects onto a linked list whose
elements are indexed by a hash table (much like the MRU entries,
but without a reordering or eviction policy) and then scan just
the list of dirty objects during the commit. Objects evicted
from the MRU would be removed from the dirty list as they are laid
down onto page images. (Per the semantics of the dirty list,
an object whose state is current on the page image does not belong
on the dirtylist).
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language that extends applications into web and mobile media.
Attend the live webcast and join the prime developer group
breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
mailing list Jdbmemail@example.com https://lists.sourceforge.net/lists/listinfo/jdbm-developer