I might be misunderstanding the context in which you're discussing this, but
I have a very hard time believing that *any* app server will provide
read-only entity beans that provide faster read times than an ordinary class
with static final variables, populated via direct JDBC access. Perhaps *as*
fast, but not faster.

Is this more or less how entity-bean caching is implemented for read-only
data in an app server? I haven't had to build one, so I don't know...

KurtC



-----Original Message-----
From: Floyd Marinescu [mailto:[EMAIL PROTECTED]]
Sent: Sunday, August 13, 2000 7:21 PM
To: [EMAIL PROTECTED]
Subject: Re: Designing Read Only Entity Beans


>As you said , using the entity bean would certainly be overhead for read
>only data ...
>Would it be good to use session bean (with JDBC code for SELECT query)
>instead.  What say ?

        I completely disagree. For read only data, if you have an
application
server that supports entity bean caching (and every notable app. server
does) or the notion of read-only beans, then it is much faster to use entity
beans for read only data.

        Consider an online car dealership. The stats of cars rarely change,
so they
could be modeled as read only car entity beans. Now if a user browses
through the inventory of cars, it will be much, much faster to grab this
data from an in memory entity bean than it would to open a connection to a
database and query for the same data every time someone browses the
catalogue.

        Asides from a mechanism for persistence, the other main value add of
entity
beans is caching. This makes entity beans a better choice over JDBC from
session beans for many cases.

Floyd Marinescu

---------------------------------
Senior Architect / Director of Marketing
The Middleware Company
http://www.middleware-company.com
http://www.TheServerSide.com
[EMAIL PROTECTED]
416-889-6115

Check out TheServerSide.com, the internets first J2EE community!!!

===========================================================================
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".

===========================================================================
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".

Reply via email to