Kevin,
 
I think that the soft/weak cache classes operate correctly.  However, I believe that the manner in which they are being used by the CacheRecordManager is not producing the desired result.  In the example that I sent, if you hold a reference to [s] in your application, the cache entry for [s] will still be cleared from the soft/weak cache -- and those are the wrong semantics.
 
-bryan
-----Original Message-----
From: jdbm-developer-admin@lists.sourceforge.net [mailto:jdbm-developer-admin@lists.sourceforge.net]On Behalf Of Kevin Day
Sent: Monday, April 24, 2006 3:51 PM
To: JDBM Developer listserv
Subject: re[6]: [Jdbm-developer] Soft/Weak cache question - it seems like we have a hole in the cache commit behavior.

Bryan-
 
mmmm - this implementation is exactly per the jdk docs for the soft/weak reference classes...
 
The implementation is solid as far as I can tell...
 
Can you come up with a unit test that results in the failure mechanism that you are concerned with?
 
- K
 
> Kevin,

The objects that are actually inserted into the soft/weak cache are not the
application objects directly, but CacheRecordManager.CacheEntry instances.
Since the application is not holding references to those CacheEntry
instances,
they go out of scope as soon as the code exits a method on the
CacheRecordManager
class.  This is counter to the intention for the soft/weak cache.  What we
need
is to drive the dirty flag and serializer references into the SoftReference
/ WeakReference objects that are held as the cache values.

Consider,

String s = new String();
long recid = crm.insert(s);

  CRM does: entry = new CacheEntry( recid, s, serializer, isDirty );
            cache.put( recid, entry );

  Soft/WeakCache does: internal.put( recid, new Entry( recid, entry ) );

Where Entry extends Soft/WeakReference.

So the WeakReference is to the CacheEntry, not to the String [s].  Holding
onto a reference to [s] does not effect the retention of the soft/weak cache
entry for [s].  The application would actualy have to hold onto the
CacheEntry
object, which it never sees.

We could fix this be expanding the interface API for the CachePolicy to pass
along the additional state {dirty flag, serializer} and driving that state
into the Weak/SoftReference Entry class used by the Weak/SoftCache class.

-bryan

-----Original Message-----
From: jdbm-developer-admin@lists.sourceforge.net
[mailto:jdbm-developer-admin@lists.sourceforge.net]On Behalf Of Kevin Day
Sent: Monday, April 24, 2006 2:15 PM
To: JDBM Developer listserv
Subject: re[4]: [Jdbm-developer] Soft/Weak cache question - it seems like we
have a hole in the cache commit behavior.


Bryan-

hmmm - not sure I understand this one...

If a weak reference is used, then the object is not garbage collected until
all other, non-weak referenced objects have been collected.  This means that
the cache allows us to retrieve an instantiated form of a given object from
the cache, even if all hard references to it have been severed.

The MRU size drives when the changes to the object are actually serialized
to bytes.  The weak reference cache determines whether deserialization is
necessary for a given fetch request.

I believe that the comments in the weak reference cache implementation
describe this in a lot of detail...

- K
 > Because it lets you adjust the degree of retention simply by changing
the  MRU size.  But the point is the same
either  way, the weak/soft cache entries are inside of the
CacheRecordManager CacheEntry  objects.  Since noone
is  holding onto the CacheEntry objects, the cache is not doing what we
want.
-bryan
-----Original Message-----
From:  jdbm-developer-admin@lists.sourceforge.net
[mailto:jdbm-developer-admin@lists.sourceforge.net]On Behalf Of Kevin  Day
Sent: Sunday, April 23, 2006 7:18 PM
To: JDBM  Developer listserv
Subject: re[2]: [Jdbm-developer] Soft/Weak cache  question - it seems like
we have a hole in the cache commit  behavior.


Bryan-


I've never understood why one would want a  weakreferencecache...  I always
use softreference myself...

- K

>
All,

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.

Thoughts?

-bryan
-----Original Message-----
From:  jdbm-developer-admin@lists.sourceforge.net
[mailto:jdbm-developer-admin@lists.sourceforge.net]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.


Bryan-


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

>
All,

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  onthe dirtylist).

-bryan
<
-------------------------------------------------------   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
_______________________________________________ Jdbm-developer  mailing list
Jdbm-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdbm-developer  <
-------------------------------------------------------  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
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Jdbm-developer mailing list
Jdbm-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdbm-developer <


------------------------------------------------------- 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
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Jdbm-developer mailing list
Jdbm-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdbm-developer


<
------------------------------------------------------- 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 http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Jdbm-developer mailing list Jdbm-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdbm-developer