>Gemstone does not use Java serialization to persist objects.
Yes, I know. I just said serialization, not Java serialization. Gemstone
has this very powerful feature and it works with elegance.
>Synchronization with the backend relational DB is still an issue,
>but what if updates occur by some process outside the
system....???
This could handled by the database as you suggested. It will be alot harder
though, and you will probably loose the portability across databases.
You could also take the hit of a failed transaction when the outdated data
gets updated in the database.
If your system requires the real time consistency then integrating with a
legacy database will require some thought to it. It's not a simple task.
You need to investigate what and how often data gets changed, then you
could have audit tables through triggers, replication technologies, etc.
If your cache is limited to a certain type of data it shouldn't be too hard
to check on a periodic level.
My main point is that you as a developer of EJB objects will be very
limited if you try to develop this yourself. Of course, it is all dependent
on the requirements of the system. In a lot of cases a simple hash table
can be sufficient. You just flush it on periodically, or when an object
reaches a certain age.
Filip Hanik
Verge Software
Frank Sauer
<frank_sauer@GEOC To: [EMAIL PROTECTED]
ITIES.COM> 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 04:56 PM
Please respond to
A mailing list
for Enterprise
JavaBeans
development
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".
===========================================================================
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".
