> My guess is that if you do not have client and entity specific state, then
> you maybe better of using stateless session beans.
Of course, but that's not really what I have been referring to, is it?
Please re-read my previous posts.
> I have to re-read the spec but if my memory serves me correctly, there
> is nothing in the spec that guarantees (or forces) a vendor to implement
> pooling. But, as you've stated, depending upon your use case, the
> costs/benefit of pooling may or may not buy you anything.
You're quite correct, it's just that in the case I've described such a
container would be pretty useless. For reference, the state-allocating
operation I referred to earlier took roughly two seconds, so the
difference between a pooling and non-pooling container would be HUGE.
I would, personally, prefer a container that gives me both options.
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".
