Sorry to chime in so late....But hasn't my CacheKey change been in since
2.4.0?

Also remember why I added the copying to the CacheKey in the first place.
What I was doing in my application code was reusing a fat-primary key so I
didn't have to reallocate one.  Thus the entity cache was getting corrupted
because I kept on changing the shared primary key instance.  I guess if
you're stupid enough to re-use an instance of a primary key, you deserve to
spend days trying to track down this problem.

So, if you're going to get rid of the MarshalledObject and all the copying,
why not just get rid of CacheKey all together?

Bill

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc
> fleury
> Sent: Tuesday, November 13, 2001 8:54 PM
> To: Scott M Stark; Jboss-Development@Lists. Sourceforge. Net
> Subject: RE: [JBoss-dev] CacheKey copy semantics and speed
>
>
> well,
>
> then you don't win,
>
> but I don't win either
>
> today is a crappy day
>
> but the fix is relevant
>
> marcf
>
> |-----Original Message-----
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> |M Stark
> |Sent: Tuesday, November 13, 2001 8:55 PM
> |To: Jboss-Development@Lists. Sourceforge. Net
> |Subject: Re: [JBoss-dev] CacheKey copy semantics and speed
> |
> |
> |Ok, but all of that time was really due to the removal of the
> |MarshalledObject.get(). Running with the CacheKey implementation
> |pre the copy gives basically the same time as the non-MarshalledObject
> |version:
> |
> |1 minute 48 seconds
> |
> |----- Original Message -----
> |From: "Scott M Stark" <[EMAIL PROTECTED]>
> |To: "Jboss-Development@Lists. Sourceforge. Net"
> |<[EMAIL PROTECTED]>
> |Sent: Tuesday, November 13, 2001 5:43 PM
> |Subject: Re: [JBoss-dev] CacheKey copy semantics and speed
> |
> |
> |>
> |> Yes it does use byte[] comparisons in a for loop. Let me give you
> |> a push in my direction. We know there is a performance drop in 2.4.4
> |> that has yet to be resolved, but profiling shows it is related to
> |> interaction
> |> with the entity cache and that the CacheKey ctor ends up being
> |the largest
> |> hotspot. By simply changing the CacheKey to use the input id directly
> |> rather than MarshalledObject, the timing of the bank unit test
> goes from:
> |>
> |> 2 minutes 43 seconds
> |>
> |> to:
> |>
> |> 1 minute 46 seconds
> |>
> |> Pretty big improvement for a trival change. That's the 80/20 rule in
> |action
> |> big time.
> |>
> |
> |
> |
> |_______________________________________________
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>



_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to