Rickard,
Disclaimer: This is a tricky subject, and I do not in any way claim to
have the final answer on this one
[Kirk] dito
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.
[Kirk] GemStone engineers decided against pooling stateless session beans as
the cost was much higher than the memory management issues. In fact, when I
got a good look at how the container manages the life cycle of the beans, I
found that they were being held in a context that was not synchronized for
concurrent access. So technically, the code is not thread safe. For all
practical purposes, it is. In their opinion, lock contention would be a
serious bottleneck in the system. So they build a bean management scheme
that avoided the need for locking. Given the size of some of the
application deloyed in GSJ, this decision seems to have worked out.
Cheers,
Kirk
===========================================================================
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".
