db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From arm...@apache.org
Subject cvs commit: db-ojb/src/java/org/apache/ojb/broker/metadata/fieldaccess AnonymousPersistentField.java
Date Sat, 24 Jan 2004 19:09:24 GMT
arminw      2004/01/24 11:09:24

  Modified:    src/java/org/apache/ojb/broker/metadata/fieldaccess
                        AnonymousPersistentField.java
  Log:
  remove workaround for object identity problem, because it doesn't really work :-(
  We need a WeakIdentityHashMap to solve the problem.
  
  Revision  Changes    Path
  1.9       +30 -61    db-ojb/src/java/org/apache/ojb/broker/metadata/fieldaccess/AnonymousPersistentField.java
  
  Index: AnonymousPersistentField.java
  ===================================================================
  RCS file: /home/cvs/db-ojb/src/java/org/apache/ojb/broker/metadata/fieldaccess/AnonymousPersistentField.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- AnonymousPersistentField.java	7 Jan 2004 19:11:10 -0000	1.8
  +++ AnonymousPersistentField.java	24 Jan 2004 19:09:24 -0000	1.9
  @@ -87,18 +87,45 @@
           return getFromFieldCache(anObject);
       }
   
  +/*
  +    TODO: Use WeakIdentityHashMap instead WeakHashMap to hold anonymous field values
  +
  +    Here is an snip of the mail from Andy Malakov:
  +
  +I found that usage of database identity in Java produces quite interesting problem in OJB:
  +In my application all persistent Java objects use database identity instead of Java reference
identity
  +(i.e. Persistable.equals() is redefined so that two persistent objects are the same if
they have the same
  +primary key and top-level class).
  +
  +In OJB, for each field declared in repository there is dedicated instance of AnonymousPersistentField
that stores
  +object-to-field-value mapping in WeakHashMap (in fkCache attribute). Despite usage of cache
  +(ObjectCachePerBrokerImpl in my case) it is possible that identical DB objects will end
up as different
  +Java objects during retrieval of complex objects.
  +
  +Now imagine what happens when two identical instances are retrieved:
  +1)
  +When first instance is retrieved it stores its foreign keys in AnonymousPersistentField.fkCache
under instance's
  +identity. (happens in RowReaderDefaultImpl.buildWithReflection())
  +2)
  +When second object is retrieved and stored in fkCache, first instance is probably still
cached
  +[WeakHashMap entries are cleaned up only during GC]. Since keys are identical WeakHashMap
only updates entry
  +value and DOES NOT update entry key.
  +3)
  +If Full GC happens after that moment it will dispose fcCache entry if the FIRST reference
becomes
  +soft-referenced only.
  +    */
       protected void  putToFieldCache(Object key, Object value)
       {
           if(fkCache == null)
           {
               fkCache = new WeakHashMap();
           }
  -        fkCache.put(new IdentityKey(key), value);
  +        fkCache.put(key, value);
       }
   
       protected Object getFromFieldCache(Object key)
       {
  -        return fkCache != null ? fkCache.get(new IdentityKey(key)) : null;
  +        return fkCache != null ? fkCache.get(key) : null;
       }
   
       /**
  @@ -134,63 +161,5 @@
       public boolean usesAccessorsAndMutators()
       {
           return false;
  -    }
  -
  -    //******************************************************************
  -    // inner class
  -    //******************************************************************
  -    /*
  -    TODO: replace this workaround with a IdentityWeakHashMap
  -    arminw:
  -    Workaround till we can use a IdentityWeakHashMap implementation.
  -    WeakHashMap use obj.equals(...) method to compare the object key in the
  -    map. Better to use an identity comparison.
  -
  -    Here is an snip of the mail from Andy Malakov:
  -
  -I found that usage of database identity in Java produces quite interesting problem in OJB:
  -In my application all persistent Java objects use database identity instead of Java reference
identity
  -(i.e. Persistable.equals() is redefined so that two persistent objects are the same if
they have the same
  -primary key and top-level class).
  -
  -In OJB, for each field declared in repository there is dedicated instance of AnonymousPersistentField
that stores
  -object-to-field-value mapping in WeakHashMap (in fkCache attribute). Despite usage of cache
  -(ObjectCachePerBrokerImpl in my case) it is possible that identical DB objects will end
up as different
  -Java objects during retrieval of complex objects.
  -
  -Now imagine what happens when two identical instances are retrieved:
  -1)
  -When first instance is retrieved it stores its foreign keys in AnonymousPersistentField.fkCache
under instance's
  -identity. (happens in RowReaderDefaultImpl.buildWithReflection())
  -2)
  -When second object is retrieved and stored in fkCache, first instance is probably still
cached
  -[WeakHashMap entries are cleaned up only during GC]. Since keys are identical WeakHashMap
only updates entry
  -value and DOES NOT update entry key.
  -3)
  -If Full GC happens after that moment it will dispose fcCache entry if the FIRST reference
becomes
  -soft-referenced only.
  -    */
  -    static class IdentityKey
  -    {
  -        Object obj_;
  -
  -        public IdentityKey(Object obj)
  -        {
  -            this.obj_ = obj;
  -        }
  -
  -        public boolean equals(Object key)
  -        {
  -            if(key instanceof IdentityKey)
  -            {
  -                return this.obj_ == ((IdentityKey)key).obj_;
  -            }
  -            else return false;
  -        }
  -
  -        public int hashCode()
  -		{
  -			return System.identityHashCode(obj_);
  -		}
       }
   }
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message