I'm not certain what you mean by populating a static final variable via
JDBC. If it's static and final, it's value is set at compile-time, correct?
Regardless, app servers with caching and read-only entity beans will keep
the entities cached inside the app server's local memory (provided the cache
is big enough to hold all the values). This means that returning a list of
read-only entities is a local, in-memory operation. The JSP/Servlet/Session
Bean to JDBC combination doesn't usually have a cache holding the ResultSet,
so there's a database query/network traffic overhead with each invocation.
Regards,
Matt Kleiderman
> -----Original Message-----
> From: Christensen, Kurt [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, August 14, 2000 3:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Designing Read Only Entity Beans
>
> 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
>
>
>
===========================================================================
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".
