On 15 Sep 00, at 9:45, marc fleury wrote:
> > 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
>
Actually, pools aren't just about preventing memory allocation and
deallocation. They are needed to help bad programmers who want
to acquire and free other resources (e.g. sockets, database
connections) in a component at a scope higher than a single
remote method invocation. The EJB landscape is littered with
callback methods to support this questionable strategy, so we
should do our part too.
-Dan
