Hi Guys,
I'm struggling with a design issue related to entity beans and in order
to get it right I wanted to make sure I knew all the Pros and Cons.
Clearly writing a container managed entity bean is easier than writing a
bean managed one (though maybe not as flexible if it maps down to a
complex table/database join :-).
Also writing an Entity bean allows me to refer to the underlying data as
an object and allows me to program in such a way as to not worry to much
about ties to a particular database, i.e. they are transportable.
But, my worry is performance related. If my bean maps to a table of
millions of rows I would have potentially millions of objects swimming
around all making remote method calls. I can see that as Entity beans
are persistent I could do whatever I like to then bean then remove it
and bring it back again if I need it, but this seems like a lot of
overhead as well. The other option is a bean pool where a bean is
brought out of the Pooled State to the Ready State, which means that
although I could only have a few beans they could by used to handle
(from the client side view) millions of beans.
In a Container managed bean this is left up to the container to manage,
but how do I do it with bean managed Entity beans?
Does anyone have a rule or design pattern for when to use Entity beans
and how to make them system resource friendly.
Any advice is appreciated.
Karl
===========================================================================
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".
