ok,
scott has put his finger on a solid fact, you can screw up your PK and the
cache key won't save you. It is not what I thought.
I think the point he makes is that even though the PK hashcode and equals
are really easy to screw up at least it is your responsibility as per the
spec.
Frankly we went the cache key route because *I* thought it was fool proof
and we had many people not paying attention to hashcode and equals, but I
realize it is not fool proof.
The other thing is that there is a bit of work in backporting but one thing
we could do is that if the class defines hashcode and equals we use it...
even if you mess it up
marcf
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Tuesday, July 10, 2001 9:24 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] Fool proof? I think not.
|
|
|I don't see why the burdon is not put on the primary key implementor. Its
|clearly documented in the spec that hashCode() and equals() are
|required for
|client use, so why not leverage this? What do we do in the general case of
|an
|unkown primary key class(type = java.lang.Object)?
|
|9.2.9 Entity bean's primary key class
|
|The Bean Provider must specify a primary key class in the deployment
|descriptor.
|
|The primary key type must be a legal Value Type in RMI-IIOP.
|
|The class must provide suitable implementation of the hashCode() and
|equals(Object
|
|other) methods to simplify the management of the primary keys by client
|code.
|
|
|
|----- Original Message -----
|From: "marc fleury" <[EMAIL PROTECTED]>
|To: <[EMAIL PROTECTED]>
|Sent: Tuesday, July 10, 2001 3:38 PM
|Subject: RE: [JBoss-dev] Fool proof? I think not.
|
|
|> |> Why? Because Serialization includes the private state of the
|> |> object. This is
|> |> a perfectly valid PK which is not handled correctly by
|CacheKey. If the
|> |> _hashCode value is marked as transient all works. The assumption being
|> |> made by CacheKey is that the only ivars in the PK are its fields
|> |> that define
|> |> its identity.
|>
|> I see, so we must generate the cachekey values by serializing only the
|> relevant fields.... pfffff here comes complexity.
|>
|> hmmmm
|>
|> marcf
|
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
