-----Original Message-----
From: A mailing list for Java(tm) 2 Platform, Enterprise Edition [mailto:J2EE-INTEREST@JAVA.SUN.COM] On Behalf Of Erik Beijnoff
Sent: Friday, January 09, 2004 6:41 AM
To: J2EE-INTEREST@JAVA.SUN.COM
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@JAVA.SUN.COM] För Steven Warren
Skickat: den 8 januari 2004 18:47
Till: J2EE-INTEREST@JAVA.SUN.COM
Ä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@JAVA.SUN.COM] On Behalf Of Erik Beijnoff
Sent: Thursday, January 08, 2004 12:38 AM
To: J2EE-INTEREST@JAVA.SUN.COM
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@java.sun.com and include in the body of the message "signoff J2EE-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help".

=========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff J2EE-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help".

=========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff J2EE-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help".