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".
