Bugs item #510397, was opened at 2002-01-29 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=510397&group_id=22866
Category: JBossServer Group: v2.4 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: William A. Kaufman (wkaufman) >Assigned to: Scott M Stark (starksm) Summary: PrimaryKey Classes and Marshalling Initial Comment: The hashCode and equals methods implemented by PrimaryKey classes are not used by JBoss (at least by default - see the CacheKey class). Instead, the hashCode and equals of the MarshalledObject constructed from the PK is used. This is fine if the serialization is done correctly (ie readObject() has been implemented right). Unfortunately, the BigInteger implementation in jdk1.3.1 has a number of fields that either should have been declared transient, or ... (your solution here). The upshot is if you use BigInteger (or BigDecimal - it has a BigInteger inside it) as your PK class or as part of your PK class, you are not guaranteed that the MarshalledObject hashcode will be unique. This is bad news for the entity caching in JBoss 2.4.4 (haven't looked at 3.0, but I assume it's the same). Attached is a simple test to illustrate the problem. This problem bit us pretty hard. A bug report's been filed with Sun. ---------------------------------------------------------------------- >Comment By: Scott M Stark (starksm) Date: 2002-02-07 22:18 Message: Logged In: YES user_id=175228 This has been fixed for the 2.4.5 release by changing the implementation of CacheKey to use the underlying key equals and hashCode method if they are implemented by the id class (not a superclass). ---------------------------------------------------------------------- Comment By: William A. Kaufman (wkaufman) Date: 2002-01-31 06:28 Message: Logged In: YES user_id=262957 I forgot to mention that this problem was introduced to maintain compatability with pre-1.3 jdk's. Here's a comment in the BigInteger readObject method: /* * In order to maintain compatibility with previous serialized forms, * the magnitude of a BigInteger is serialized as an array of bytes. * The magnitude field is used as a temporary store for the byte array * that is deserialized. The cached computation fields should be * transient but are serialized for compatibility reasons. */ A work-around is to serialize and de-serialize the BigInteger to ensure that "cached computation" fields of BigInteger (bitCount, bitLength, lowestSetBit, firstNonzeroByteNum, and firstNonzeroIntNum) have all been reset to their initial values. A kluge. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=510397&group_id=22866 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
