You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by ar...@apache.org on 2005/12/06 13:33:02 UTC
cvs commit: db-ojb/src/java/org/apache/ojb/broker/util ReferenceMap.java
arminw 2005/12/06 04:33:02
Modified: src/java/org/apache/ojb/broker/metadata/fieldaccess Tag:
OJB_1_0_RELEASE AnonymousPersistentField.java
src/java/org/apache/ojb/broker/util Tag: OJB_1_0_RELEASE
ReferenceMap.java
Log:
replace ReferenceMap with commons-ReferenceIdentityMap, declare ReferenceMap as deprecated
Revision Changes Path
No revision
No revision
1.13.2.1 +28 -29 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.13
retrieving revision 1.13.2.1
diff -u -r1.13 -r1.13.2.1
--- AnonymousPersistentField.java 4 Apr 2004 23:53:35 -0000 1.13
+++ AnonymousPersistentField.java 6 Dec 2005 12:32:54 -0000 1.13.2.1
@@ -17,10 +17,8 @@
import java.util.Map;
+import org.apache.commons.collections.map.ReferenceIdentityMap;
import org.apache.ojb.broker.metadata.MetadataException;
-import org.apache.ojb.broker.util.ReferenceMap;
-
-//import org.apache.commons.collections.ReferenceMap;
/**
* This class handle an anonymous persistent fiels for 1-1 association,
@@ -51,30 +49,31 @@
}
/*
- 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.
+ Use ReferenceIdentityMap (with weak key and hard value setting) instead of
+ WeakHashMap to hold anonymous field values. Here is an snip of the mail from Andy Malakov:
+ <snip>
+ 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.
+ </snip>
*/
protected void putToFieldCache(Object key, Object value)
{
@@ -82,7 +81,7 @@
{
if (fkCache == null)
{
- fkCache = new ReferenceMap (ReferenceMap.WEAK, ReferenceMap.HARD, 10, 0.75f, true);
+ fkCache = new ReferenceIdentityMap (ReferenceIdentityMap.WEAK, ReferenceIdentityMap.HARD, true);
}
if (value != null)
fkCache.put(key, value);
No revision
No revision
1.6.2.1 +2 -1 db-ojb/src/java/org/apache/ojb/broker/util/ReferenceMap.java
Index: ReferenceMap.java
===================================================================
RCS file: /home/cvs/db-ojb/src/java/org/apache/ojb/broker/util/ReferenceMap.java,v
retrieving revision 1.6
retrieving revision 1.6.2.1
diff -u -r1.6 -r1.6.2.1
--- ReferenceMap.java 22 May 2004 09:51:25 -0000 1.6
+++ ReferenceMap.java 6 Dec 2005 12:33:01 -0000 1.6.2.1
@@ -82,6 +82,7 @@
* can use {@link java.util.Collections#synchronizedMap} to
* provide synchronized access to a <Code>ReferenceMap</Code>.
*
+ * @deprecated use {@link org.apache.commons.collections.map.ReferenceIdentityMap} instead.
* @author Andy Malakov
* @version $Id$
*/
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org