I was under no impression that a server's main function was to cache
objects. I was under the impression that an EJB server might choose to cache
instances (not state) of both session and entity beans to improve performance.
I was not under the impression that EJBs should be picked for performance,
though that might be arguable at some point down the road. Instead, this is
simply to improve however fast an EJB server works. Since object allocation
and deallocation are THE most expensive things to do in Java, and an EJB raises
this by orders of magnitude I would think, the motivations to keep instances
around and reuse them is high. I'd want to do that even in a simple little
server application without EJB support. So, in that context, remove is just a
suggestion to the container which might choose to destroy the instance or keep
it around for reuse by another caller later, right? Again then, can I force
actual destruction of the session or entity instance? Thanks.
Ken
Or, of course, I could use CICS and not even have to be in Java since CICS
does absolutely eveyrthing a programmer could ever wish for :-).
>
>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".
>
===========================================================================
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".
