----- Original Message -----
From: "Dale Bronk" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Wednesday, April 05, 2000 3:54 PM
Subject: Re: Is CMP is useless?
<snip>
> They create a ton more sql calls than if I simply do my own sql objects
for
> any type of big criteria searches. I for one only use finder methods when
a
> single row is returned. When more than one row is returned the overhead
is
> too much for me to take.
</snip>
Really? Can you elaborate on what you mean by this?
A Collection finder only issues one database call for loading all the
entities (and grabbing cached instances from the cache so they dont have to
be reloaded in tha case) unless you're using BMP (which we advice against if
it's not *absolutely* needed - BMP will always be slower - less room for
optimization). When using CMP you also have lazy loading of relational
(OR-mapped) fields etc - something that would not be fun to create or
maintain if using handcrafted JDBC.
Another common mistake is to see web servers talking to remote, dedicated
ejb-servers in a cluster as the most efficient solution in a cluster. We
recommend the opposite arch, running both HTTP and EJB on all the nodes
(general recommendation of course - there are cases where this is not a
viable solution). This results in better performance due to staying away
from remote calls (which include database hits) as much as possible. The
nodes will use their local entity cache in the common case and also use
local session instances. There will be three different types of clustering
support, which one you want to use will be selected at deployment time (some
sacrifice 100% update atomicity which is still a viable solution in more
cases than you'd generally assume). A news item for instance is mostly "read
only" and can hence be cached *a lot* more efficiently if you allow <= 50ms
lag in update propagation to the other nodes.
There seems to be a lot of "FUD" regarding entities out there - something
expect when it comes to new technology I guess. Entities provide a very
efficient data cache unless you need 100% atomicity among nodes, something
that you simply dont have time to do in an average project (or rather
"shouldnt" - usually not worth it) since it has to be transactionally aware
etc.
Right now most of the info comes from vendors like us and not so much from
the user community which leads to biased opinions. For instance we will
probably promote using EJB technology more often than other vendors who
arent as EJB oriented (although we do try to keep it on a technical level)
and Oracle will probably promote minimal abstraction of the database since
that benefits them. The user community's knowledge is bound to improve so
this situation will most likely change soon (which is a good thing).
/Magnus Stenman, the Orion team
