Rickard Öberg wrote:
>
> > 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.
Can you give us some idea of the problem you solved by having state associated
with the entity context? Would I be right in thinking of things like socket
connections, connections to legacy systems, or business rules loaded from a
database are best associated with the entity (or session) context?
Ian McCallion
Alexis Systems Limited
Romsey, UK
===========================================================================
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".
