Yes, several vendors are implementing caching mechanism.
The two most solid implementations of cached entity beans would be Gemstone
and Persistence PowerTier.
both of them have a shared and synchronized cache over multiple VMs
available. In persistence the cache in tightly coupled with their OR
mapping technology.
In Weblogic you can achieve similar caching by using TOPLink which does
it's own caching. However Weblogic's caching mechanism is not shared and
synchronized over multiple VMs.
In your scenario I've been told that having an Entity Bean (EB)
instantiated can be expensive. If you are only passing read only data then
you don't need the heavy transactional logic that comes with an EB. You
could only pass data by value instead of instantiating remote references
that would actually create network connections and limit the scalability of
your server.
This is just a my initial thought's. I'd like to see what others have to
say
Filip Hanik
Mike Fontenot
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
T> cc:
Sent by: A Subject: Performance - Caching Entity
Beans?
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@jav
a.sun.com>
11/15/99 09:22 AM
Please respond to
A mailing list
for Enterprise
JavaBeans
development
All,
I have a question regarding the performance and scalability of entity beans
(EB). I understand that EBs are mapped to persistent storage, usually a
relational database. Also, that the EJB container can create a pool of EB
instances for use by lots of clients.
However, it seems that unless the EJB vendor implements some kind of
instance caching mechanism, the EJB server is just a 'pass through' to the
relational database. Is this the typical case? If so it seems that this is
a pretty non-scalable answer.
Here is my scenario: I have a catalog(s) of products of primarily read only
objects, that are accessed by thousands of clients (remote client ->
session
beans -> entity bean). I would like to instantiate that catalog then leave
it cached in the EJB server unless some other process comes along to update
it. At that time the updated portion of the catalog could be flushed and
reloaded. My goal would be to keep most of the catalog in memory and
eliminate the database hit(s) unless a client was accessing some portion of
the catalog not yet in memory. There could be lots of catalog at any one
time.
Is something like this a common requirement/implementation among those of
you who have/are implementing EJB based systems? Any recommendations for
EJB
servers that have this caching capability? How do they make this caching
function availble to the developer (deployment descriptors, explicit code),
is caching available for both BMP and CMP?
Thanks in advance,
Mike Fontenot
========================================
Mike Fontenot - Object Systems Architect
Polygon Network, Inc.
Golden, CO
========================================
===========================================================================
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".
