At 00:09 22.01.00 , you wrote:
OK, here's an opinion from someone who heavily uses entity beans.
What our experience has been is that in many applications we deal with
there are parts that have to handle many concurrent requests and parts that
don't. let's take a typical example taken from a recent project. we built a
custom web content management system for a client of ours that will be used
by 10-15 people to administer parts of their website with workflow,
authorization etc.. The content on the website is generated by servlets
accessing EJBs on top of a relational database and the administration tools
use the same architecture. the entire administration application has been
written using autogenerated cmp entitybeans which make life so much simpler
especially if you use things like lazy loading bean relationships using
finder methods etc.. we are going to use the orion server for deployment
(www.orionserver.com), which has very good entity bean performance which is
good enough for 15 people working with the tool simultaniously. we don't
expect the performance of the entity bean code to be good enough for the
web-frontend under heavy load but that's the trivial part of the
application. if we put a caching mechanism or handcrafted sql-queries
there, we still save LOTS of work in the administration part because CMP
entity beans, if used properly, really give you a useful api to manipulate
your data model even if the mapping facilities are not sophisticated (which
is the case for orion).
so my advice would be to really look at which parts of your application
need to be tuned for performance and which might afford a little overhead
introduced by naively mapping anything to entity beans. the project I
referred to was the first we did with this rather dumb brute force approach
but it worked great in terms of production time and stability
(autogenerated code usually doesn't contain errors, huge factor IMHO).
just my 2c
robert
>I've heard that the general rule of thumb is that if the data is for the
>most part just listable -- you should use a stateless session bean
>w/ JDBC. For example, if you have an E-Commerce site with 100,000
>SKUs, I would think the stateless session bean approach would be
>better. Definitely would perform better.
>
>Is anyone out there running a production site with a large number of
>entity beans? I'd be curious to know how it performs.
>
>Deciding between stateless session beans w/ JDBC or entity beans has
>definitely been the big issue in designing my application. I still don't
>feel
>confident in making a decision. I guess trying it both ways would be the
>right way
>to do it -- but who's got time for that? =)
>
>Anyone have any experiences to share?
>
>Neal
>
>===========================================================================
>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".
(-) Robert Kr�ger
(-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
(-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
===========================================================================
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".
