This thread is a little funny to me. We got the idea of a cache key
from a thread on ejb-interest, where Jonathan Wheedon (Borland's
very intelligent alien...their Rickard, so to speak) described how it
was implemented in IAS. But if memory serves me, the trigger for
the thread was how the fat key pattern for BMP was failing in IAS
because it involved using "non-key" information in the key's private
state. So I thought we knew about this from the start. Oh, well, as
Santayana said...
-Dan
On 10 Jul 01, at 23:03, marc fleury wrote:
> 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
