User: mnf999
Date: 01/11/13 15:41:20
Modified: src/main/org/jboss/ejb CacheKey.java
Log:
The performance of the copy semantics is just too expensive, if we want to enforce
the copy semantics in the future (commented out here) then we should put that in some
cache class that can read a configuration field.
This is intended to speed up the finder (large ones) and 2.0 CMR that makes
extensive use of these.
Revision Changes Path
1.17 +11 -1 jboss/src/main/org/jboss/ejb/CacheKey.java
Index: CacheKey.java
===================================================================
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/CacheKey.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- CacheKey.java 2001/08/03 17:15:43 1.16
+++ CacheKey.java 2001/11/13 23:41:20 1.17
@@ -29,7 +29,7 @@
*
* @author <a href="mailto:[EMAIL PROTECTED]";>Marc Fleury</a>
* @author <a href="[EMAIL PROTECTED]">Bill Burke</a>
- * @version $Revision: 1.16 $
+ * @version $Revision: 1.17 $
*/
public class CacheKey
implements Externalizable
@@ -78,11 +78,21 @@
this.id = null;
try {
+
+
+ /*
+ * FIXME MARCF: The reuse of the primary key is an "exception" and this fix
makes
+ everyone pay an hefty price. If we really want this behavior we can put
it in
+ the cache. Is there a test for this?
+
// Equals rely on the MarshalledObject itself
mo = new MarshalledObject(id);
// Make a copy of the id to enforce copy semantics and
// allow reuse of the original primary key
this.id = mo.get();
+
+ */
+
// Precompute the hashCode (speed)
hashCode = mo.hashCode();
}
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
