It's certainly possible to have a stateful session bean that holds a
hashtable of objects. As each object is pulled from the database, the object
is inserted into the hashtable and referenced by the objects key.
The trick is how to get the bean to know when to re-read the database for an
updated value. This piece of the puzzle can be addressed by JMS. Your
session bean could receive a message that was propogated by another bean in
the system that changed the object you are interested in.
I'm not sure if the transactional caches found in PowerTier or Gemstone
would help you much here. [If I'm wrong, I'm sure that Chris or Christine
will jump all over this.] There products would certainly serve well as the
hashtable in the above scenario, but I think you would get better response
using your own hashtable...
jim
----- Original Message -----
From: Mike Fontenot <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 15, 1999 12:22 PM
Subject: Performance - Caching Entity Beans?
> 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".
