> It's the same thing as with the remote invocations (double
> serialization, where the last step has very low overhead).
fair enough
> > 2- do we know that they behave nicely or are we prettier with
> the reusable
> > ones?
>
> I asked Peter Jones on the RMI team about this (who wrote the MO code),
> and have also talked to the JRockit JVM (the Swedish server JVM) guys
> about this. Peter said that it wouldn't be a problem, and the JRockit
> guy said something like "DO NOT CACHE *ANYTHING*! WAAAH! We can handle
> that through garbage collection mgmt *MUCH* better than you can" Yes, he
> was pretty upset about the general idea of Java code doing caching. He
> didn't even understand why we wanted to use pools for the EJB's, because
> it seems as though if the instantiation overhead is fairly small (i.e.
> set*Context doesn't do much) you don't need a pool at all with newer
> JVM's, since they are so good at memory management. That's the
> impression I got anyway.
>
> So, I guess the answer is: yes, they behave nicely. :-)
LOL since when do *you* believe marketing pitches :)))
hmmm that I am not so sure about... I mean that it is their selling point.
We need to see that it is OK before we do away with ALL pools in jboss and
EJB in general :))
actually we could bench it and see.... hmmm a TODO I guess
marc
>
> /Rickard
>
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
>
>
