I think Rickard is true here.
Indeed, there are so many object instantiations anyway, even if the beans are
pooled, that I don't think this is the main reason for pooling. Just think about
it: ach time state is loaded from the database, the driver will create lots of
objects anyway. Moreover, as the parameters and return values are normally passed
by value, this also creates lots of objects (for example, each time a getData() is
called on an EB, a new value object is created).
But, as Rickard mentions, the code in setEntityContext() might be expensive: first
because the container must store objects in this context, and second, because this
is usually the place where other beans are looked up in JNDI. If the beans are
colocated, this is not a heavy operation, but if they aren't, JNDI lookups might
become very expensive without pooling.
Just my two eurocents...
Rickard Öberg wrote:
> Disclaimer: This is a tricky subject, and I do not in any way claim to
> have the final answer on this one.
>
> Now, on with the show..
>
> > What you say is true, but I thought the main savings were in object creation
> > and garbage collection. That is why stateless session beans (which normally
> > will have no state whatsoever) are pooled isn't it?
>
> Well, a year ago that might have been true, but now I'm not so sure,
> since doing manual object pooling in Java code might actually counter
> the memory management algorithms of modern JVMs. This is what I have
> been told anyway (by JRockit engineers).
>
> So, if this is actually true, then there would be no point in doing
> pooling of stateless session beans either. Just instantiate as needed,
> and don't bother with it. I have no problem seeing why this could be
> true, but I haven't done any extensive testing of this.
>
> Again, though, this assumes that setEntityContext is cheap. If you have
> a case where that callback actually does heavy operations, then all bets
> are off, or at least the above reasoning.
>
> regards,
> Rickard
>
> --
> Rickard Öberg
>
> Email: [EMAIL PROTECTED]
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
