After reading the message in this thread, I think people are making a
simple problem too complex. Even I would stay away from EJBs and stuff just
for the sake of caching. We use a caching toll called "oscache". It does
exactly what the original poster wants.
Oscache uses javagroups underneath for messaging. It works for me in a
clustered environment perfectly for me. Basically what OsCache does is: It
sends notifications to all servers that are bind to a particular address,
when a particular object in a cache (lets say on server1) is flushed. This
notification flushes the same object in each server's cache. That way stale
date is flushed in all servers.
Its very simple to use and I think it solves the exact problem.
You can look at oscache at http://opensymphony.com/oscache/. The tool can
also use JMS for sending notifications.
Praveen
On Fri, 9 Jan 2004 09:41:11 -0600, Jeff Jensen <jeffjensen@(protected)>
wrote:
>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)".
===========================================================================
To unsubscribe, send email to listserv@(protected)
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected)".
