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 [EMAIL PROTECTED] java.util.Collections#synchronizedMap} to
* provide synchronized access to a <Code>ReferenceMap</Code>.
*
+ * @deprecated use [EMAIL PROTECTED]
org.apache.commons.collections.map.ReferenceIdentityMap} instead.
* @author Andy Malakov
* @version $Id$
*/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
