To be blunt, this *is* a very common misconception. Unfortunately, an EJB
server is commonly thought of as a big object cache, that effectively
eliminates repretitive reads from the database. In fact, most EJB servers
provide an option to enable this behavior.

If your application can guarantee the EJB server exclusive access to the
underlying database, great, have at it. If you ever want to scale your beans
to two containers, forget it. If you have legacy apps, other apps, reporting
tools, etc. modifying the database, forget it.

EJB is best thought of as a *transaction* server. In most cases, EJB won't
even give you a performance gain over the "old-fashioned" CORBA/RMI factory
approach. But it will give you transactions and scaleability.

jim

----- Original Message -----
From: Laird Nelson <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 18, 2000 9:34 AM
Subject: Re: Caching of read-only DB contents in an EJB


Rickard �berg wrote:
> Almost but not quite. Readonly data can be cached by stateless session
> beans. If you need read/write caching then either use Entities or a RMI
> object.

On the off chance that it's not just me:

I'm quite confused by this thread.  I was under the impression that one
of the reasons that *entity* beans exist at all in the specification is
to effectively serve as data caches for the underlying data store.  That
is, there is a person record on disk somewhere, but you deal with the
Person entity bean instead, because it will usually be (activated) in
memory.

Could someone please explain to the slow and thick among us :-) why that
is not a good idea, or why it is a less than optimal idea, or why we
should be using stateless session beans, or why we should not work with
entity beans in this problem domain, or why we should be using some
other odd beast (e.g. RMI objects) to accomplish the same thing?

Cheers,
Laird

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