RE: re[6]: [Jdbm-developer] Soft/Weak cache question - it seems like we have a hole in the cache commit behavior.

[Bryan T. <tho...@sp...>]

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: jdb...@li...
[mailto:jdb...@li...]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: jdb...@li...
        [mailto:jdb...@li...]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:  jdb...@li...
        [mailto:jdb...@li...]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:  jdb...@li...
        [mailto:jdb...@li...]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
        Jdb...@li...
        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
        Jdb...@li...
        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
        Jdb...@li...
        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
Jdb...@li...
https://lists.sourceforge.net/lists/listinfo/jdbm-developer