Gemstone does not use Java serialization to persist objects.
They use their own proprietary mechanism that performs much better
than serialization. A gemstone PCA Hashmap would work very well in
this scenario. It is persistent, transactional and accessible from
all sessions. We use this extensively and we actually don't use
Entitybeans at all, just PCA objects for those objects that need to be
shared between multiple clients.
I don't understand the point about 'all the logic for the cache'.
Persisting objects in Gemstone is the easiest thing in the world. Just
bind an object into a JNDI context or link it to an existing persistent
object et voila, it's persistent...
Synchronization with the backend relational DB is still an issue, I agree.
If all updates occur through the appserver it can be handled at that level,
by one bean calling an API on another bean, or through JMS or something
like that, but what if updates occur by some process outside the
system....???
I don't know. I toyed with the idea of writing a java stored procedure
(we use Oracle) that calls back into the appserver, or uses JMS or something
like that, but I haven't actually delved into that yet, simply because it
doesn't happen in our system.
Frank
The Technical Resource Connection
Tampa, FL
http://www.trcinc.com
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Filip Hanik
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".
