You said: "But, my worry is performance related."
Personally I feel the current bean managed persistence contract is not
conducive to performance. The performance overhead can be somewhat reduced
with an object/relational mapping tool such as TopLink. Unless you have some
unusual domain model i.e. scientific data and/or a container that does not
have a good container persistence engine then I would say you would be
better off with cmp entity beans.
Kind regards
William Louth
-----Original Message-----
From: Karl Roberts [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, April 11, 2000 12:15 PM
To: [EMAIL PROTECTED]
Subject: Pros and Cons of Entity beans/JDBC
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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
