CacheRecordManager inserts CacheEntry objects into the weak value cache. Those objects have attributes

containing the 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 onto the

CacheEntry objects itself, but only the object reference, it seems that the CacheEntry entries in the weak value

cache 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.





-----Original Message-----
From: []On Behalf Of Kevin Day
Sent: Monday, April 17, 2006 10:46 AM
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.

I don't 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 is made).
- K
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 dirty list).
------------------------------------------------------- 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! _______________________________________________ Jdbm-developer mailing list