Well,
scott wrote to me "it's not worth arguing about" and I sort of agree,
but for the sake of completeness, at least on my part, here goes
|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
1- you knew about it, I certainly didn't, speak up danny o' speak up
2- why is BMP/CMP relevant at all? please explain.. afaict it is a problem
with cache misses, it is a "CacheKey"
3- don't get pompous with pattern talk on *me*, danny boy :)
|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...
I don't know Mr Santayana, but I am sure he didn't know about the fat key
thingy.
Anyway, back to what I said in a previous mail, at this point the best I can
think of is
1- if user doesn't define H&E then use the cachekey mechanisms
2- if user does define H&E use cacheKey to cache the value instead, we keep
the CK structure, we save 80% shooting in foot, we remain spec compliant if
you are spec compliant
I am leaving for spain in a few hours will take 2 weeks there and plan on
working on JMX so if someone want to modify the initialization of the
cachekey to detect the presence of hashCode and equals that would be great,
you should also only work on the hashcode for the equals will speed stuff.
now, if you are not spec compliand && you fuck up the state of your key (non
key state in the key) then you are on your own, and we document that part.
I think that is the solid point that scott made quite explicitely, there is
no fool proofness here, the rest is taste and making life easier for our
users.
marcf
|
|-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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
