Rickard,
My guess is that if you do not have client and entity specific state, then
you maybe better of using stateless session beans.
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.
Kirk
----- Original Message -----
From: "Rickard Öberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 5:42 AM
Subject: Re: Entity Beans
On Thu, 1 Mar 2001 04:52:11 -0800, Kirk Pepperdine <[EMAIL PROTECTED]>
wrote:
>but what's the point of pooling entity beans?
>
I'd say there are two cases. If your EntityBeans do not have a lot of
client and entity identity specific state, then it might just as well be
better to not to pool Entity instances, since todays JVM's do quite a
decent job at memory mgmt anyway.
However, if you allocate a lot of state in setEntityContext (i.e. state
that is not client and not identity dependent) it's another deal. As it
happens I had a case like this where the pooling of instances was
absolutely critical to getting decent performance.
So, as usual, it depends on the particular usecase. At least the EJB
contract allows it.
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".
