CacheKey did not always work when the key was invalid and this was another reason it was removed. If it could not be foolproof it should not be done.
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 29, 2002 9:45 AM Subject: RE: [JBoss-user] INSERTING AN ALREADY EXISTING BEAN > That's because JBoss used to handle primary keys differently. Before, PKs > were wrapped in a JBoss object called CacheKey. The CacheKey helped out > when people didn't implement hashCode or equals correctly, but CacheKey was > a performance problem so it was removed. > > Bill > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, May 29, 2002 11:24 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-user] INSERTING AN ALREADY EXISTING BEAN > > > > OK, mea culpa. All of our primary keys inherit from an abstract class > > that deals with cacheing the keys hash code. The base class has a private > > member called _hash. Making this _hash transient FIXED the problem. > > Looks like we were getting an inconsistent hash serialized at some point. > > This is amazing since we've been running our EJBs for ages now and this is > > the first time we've had a problem like this. > > > > Regards > > > > Eric _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
