Indeed, there are so many object instantiations anyway, even if the beans
are
pooled, that I don't think this is the main reason for pooling. Just think
about
it: ach time state is loaded from the database, the driver will create lots
of
objects anyway. Moreover, as the parameters and return values are normally
passed
by value, this also creates lots of objects (for example, each time a
getData() is
called on an EB, a new value object is created).
But, as Rickard mentions, the code in setEntityContext() might be expensive:
first
because the container must store objects in this context, and second,
because this
is usually the place where other beans are looked up in JNDI. If the beans
are
colocated, this is not a heavy operation, but if they aren't, JNDI lookups
might
become very expensive without pooling.
[Kirk] I guess this combined with my experience with JDBC remind me why I
almost always use an OODB.
===========================================================================
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".
