You are correct. I didn't mean to use stateful session bean. *Stateless*
session bean is what I wanted.
You are also correct that a hashtable (or similar) does not scale well. It
would only be useful if the absolute number of entries are known beforehand,
and this number was manageable given the memory constraints. Eventually, if
every record in the DB was requested, the hash would hold every object.
You could certainly create a fixed length array and store a timestamp
representing the last time the record was read. Sort the array by timestamp,
pushing records off the end as newer objects are added.
On the flip side, it would work with all containers, whether they have a
persistent cache or not.
jim
----- Original Message -----
From: Filip Hanik <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 15, 1999 3:36 PM
Subject: Re: Performance - Caching Entity Beans?
> A stateful session beans belongs to only one client and one client only.
> That is the problem with this solution. If I access a session bean from a
> different client then I will not get the same session bean. So the cache
is
> not shared. You could write another session bean that access your cache
> session bean as a set identity.
>
>
> However this cache will not scale that well either. What if the size of
> data grows. Gemstone will serialize objects that are not being used to
save
> memory and enhance performance. So now you will have to implement all the
> logic for a cache, which is definitely a challenging thing. A regular EJB
> container does the same thing with beans.
>
>
> JMS is definitely a good way to synchronize the data when an update
occurs.
> It's probably the preferred way in a Java application server.
>
>
> Filip Hanik
> Verge Software
>
>
>
>
> James Cook
> <[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
> M> cc:
> Sent by: A Subject: Re:
Performance - Caching Entity Beans?
> mailing list for
> Enterprise
> JavaBeans
> development
> <EJB-INTEREST@jav
> a.sun.com>
>
>
> 11/15/99 12:17 PM
> Please respond to
> A mailing list
> for Enterprise
> JavaBeans
> development
>
>
>
>
>
> 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".
>
>
===========================================================================
> 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".
