Thank you Martin (and Ken), that was indeed a good article.
If I understand correctly, then, in the case of BMP I can use proprietary
DB-pooling for data access, and use the Instance Pooling property of EJB to
implement row level caching.
I know that more sophisticated caching capabilities are a property of the
appserver. How exactly do those fit with EJB? Would it be via CMP and
fancinesses in the Deployment Descriptor? If so, how do I control things
like explicitly expiring certain rows from the cache -- it seems you'd need
an API call.
Or should the appserver offer caching and other services as APIs
independent of EJB? In this case I'm still a little perplexed about the
role of EJB (given that I have connection pools). Is it simply to more
effectively manage memory or other resources because the container controls
the number of bean instances open?
-Ben
At 08:58 AM 5/21/99 +0200, you wrote:
>
>There is a good article out there that explains
>the concepts of EJB with respect to scalability.
>You find it here: http://www.objectwatch.com/issue18.htm
>(ObjectWatch Newsletter 18 - In the Fishbowl; Scalability in EJB and MTS)
>
>To summarize its main points:
>
>- The spec. doesn't define any specific mechanism for pooling and
> db connection reuse
> (in fact Weblogic and others do a lot of fancy things on that...)
>
>- But: EJB does not use a Just-In-Time-Activation algorithm for
> instance management; instead it uses another instance management
> algorithm called Instance Pooling.
> (the middle tier instances - session or entity beans -
> are themselves pooled, not the db conn.)
>
>
>With regards,
>Martin
===========================================================================
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".
