It's a common misconception to belive that an EJB server's main function is
to act as an object cache. This is certainly *not* the case.
*Some* EJB containers will have a flag that you can set whereby an EJB
server can mimic a cache. Beans will not be immediately written to the
database, or beans will not be re-read from the database until they expire.
According to the spec (section 9.1.10), this is considered Option A, and it
is one of the indicated ways that a container can persist (or not persist)
state. This option depends on the bean being the sole manipulator of the
data. In a real-world application, this is hardly ever the case. Not all EJB
containers will support this option.
*All* EJB containers will support Option B or C which require, at the bare
minimum, a database read at the beginning of every new transaction. This
causes much more database access than Option A, and is significantly slower.
For most of us, it is also, very necessary!
Your statement, "IF part of the mechanism to improve perforamnce in an EJB
server is to cache bean instances, it would seem that remove is just a
suggestion.", is correct however your interpretation is not. The bean's
*instance* is cached, but its *state* is not.
<soapbox class="not Microsoft SOAP">
When all is said and done, I don't think the real world will recognize EJB
as a runtime performance (speed) champion. That's more of a marketing slant.
It's sexier than stating, "EJB will get you to market quicker!", although it
shouldn't be.
I've yet to develop any applications that run faster because of the EJB
paradigm. What I do believe in, however, is EJB's ability to provide a
component platform that keeps me sane and allows me to take advantage of
security, transactions and persistence in a logical and consistent manner.
The goal for me is to discover repeatable success, and EJB is the best
opportunity I've seen to make this a reality.
</soapbox>
jim
----- Original Message -----
From: Kenneth D. Litwak <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 26, 1999 2:20 PM
Subject: Is remove just a suggestion?
> IF part of the mechanism to improve perforamnce in an EJB server is to
cache
> bean instances, it would seem that remove is just a suggestion. Is there
a way
> to force the ejb server to take remvoe as an actual command and not a
> suggestion? Thanks.
>
>
> Ken
>
>
===========================================================================
> 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".
