Not knowing your situation and special needs that dictate creation of a custom
data caching service, Devil's advocate here...
A performant application usually caches some data. There are a number of
benefits to using entity beans, including the data caching they do for
you, "for free".
Are you sure the caching done by the entity beans is not enough for your
situation?
What are the decision points that lead you to think the application requires
extra caching?
You could encounter plenty of development work to add your own caching and
problems from its use for little gain. Be sure the gain is worth the extra
layer's development, debugging, and maintenance!
-----Original Message-----
From: Erik Beijnoff [mailto:erik@(protected)]
Sent: Friday, January 09, 2004 8:41 AM
To: J2EE-INTEREST@(protected)
Subject: Re: Shared cache best practices?
Ok. Nice to hear another opinion. It's always good to get another view on
things.
My problem in short was how to keep caches living on separate machines in synch
with each other, when the underlying data (database) may be changed without the
caches being aware of it. The response was mostly to redesign my implementation
to use Entity Beans with a Facade that I communicated with that in turned had
single access to the database.
I myself had an idea of letting the caches register themselves in a single
location, and then handle invalidation requests from the updating application
server through HTTP or RMI whenever any of the application servers updates the
database.
I'm not sure how I will handle it, the implementation is a month or two away,
so I'll think about it until then. What you describe may be applicable. We'll
see.
Regards Erik Beijnoff
-----Ursprungligt meddelande-----
Från: A mailing list for Java(tm) 2 Platform, Enterprise Edition [mailto:J2EE-
INTEREST@(protected)
Skickat: den 8 januari 2004 18:47
Till: J2EE-INTEREST@(protected)
Ämne: Re: Shared cache best practices?
Entity beans are not really a good solution for any situation and I think
should be culled from the herd of J2EE. I don't recommend you go down that path
as it will not likely give you good performance, scalability, or reduced
complexity. I have a large CMP Entity Bean application (luckily successful) and
I am warning you away from this approach.
I didn't really hear enough about your situation to suggest a good caching
mechanism. The approach I took was to front my EJB calls with a wrapper who
returns cached data if the data has not been invalidated, when data is posted,
objects in the cache are invalidated via a notification to each invalidated
cached object (objects register to be notified when they are put in the cache).
But again, I don't know if this is applicable to your situation.
Regards
Steve
-----Original Message-----
From: A mailing list for Java(tm) 2 Platform, Enterprise Edition [mailto:J2EE-
INTEREST@(protected)
Sent: Thursday, January 08, 2004 12:38 AM
To: J2EE-INTEREST@(protected)
Subject: Re: Shared cache best practices?
Thanks for the responses. You've been verry helpful. I've gotten some
alternative approaches to think of it, and those of you who have answered seems
to lean towards the Entity Beans approach.
> Depending on your container, you may get automatic invalidation for free -
> by using the appropriate "commit option" (without needing JMS).
> This is all assuming that all modifications to the tables that have the
cached data are being done through entity beans.
> In any event, it seems entity beans would be a good fit. You will need to
decide whether to
> keep your strategy of separate caches per web server (which will mean an app
server local to each web server).
For the moment I am not using Entity Beans or EJB. Just a domain model made out
of Pojos manipulated through a DB Peer, so it's really not an app server for
each web server, rather several web server with caches. If I where to use
Entity Beans, do they make a good joob replicating over several servers, or can
I expect the app server holding the Entity Beans to become a bottleneck in the
future?
Best regards Erik Beijnoff
===========================================================================
To unsubscribe, send email to listserv@(protected)
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected)".
