<vendor, but you asked for, or someone did anyway...>
If you put these shared objects in GemStone/J's PCA, then each SB maps into
those shared objects. GemStone/J doesn't serialize, but rather puts objects
on pages. There are LRU algorithms that keep frequently access objects in
cache...
GemStone/J also provides shared Q's, which can be used like you are
suggesting to use JMS. Ours are rather easier to use, but non-standard as I
am sure some opportunistic other vendor will gleafully point out ;-)
</vendor>
-Chris.
> -----Original Message-----
> From: Filip Hanik [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, November 15, 1999 3:37 PM
> To: [EMAIL PROTECTED]
> 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".
