Hi Marc,
You're right. That was kind of an annoying e-mail. Sorry. And I'll try
never to say "pattern" again, LOL. Still friends? :-)
By the way, if anyone is interested in finding out what the heck I
was talking about, the origins of the serialization cache key in
Jonathan Weedon's work is referenced here:
http://www.mail-archive.com/jboss-dev@list.working-
dogs.com/msg03472.html
And the original ejb-interest discussion it references about cache
key and "non-key fields" is referenced here:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0009&L=ejb-
interest&P=R17131
I came to this thread late because I've been skimming the last few
weeks (shame on me), otherwise I would have mentioned this
earlier.
-Dan
P.S. If memory serves, Santayana was a COBOL programmer, so I
should really find someone better to quote. Also, if J. Weedon
subscribes to this list: sorry about spelling your name wrong.
On 11 Jul 01, at 14:06, marc fleury wrote:
> 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
