One thing that I don't think people have thought of. How about a light/poor mans JMS implementation. In this case, the webserver that gets triggered to reload the translations notifies the other webservers via a GET/POST request to a special servlet. Yes, this means that setup is a little more complicated but it avoids the extra traffic of polling the app server. Heck, if you want to you can have the webservers register with the app server by add records to the database of the IP address of the webserver.
Paul Franz
----- Original Message -----
From: "Matt Liotta" <[EMAIL PROTECTED]>
Date: Tue, 4 Mar 2003 20:12:33 -0500
To: "jdjlist" <[EMAIL PROTECTED]>
Subject: [jdjlist] RE: Caching of semi-static data across webapps
If the DB solution looks interesting, but you are concerned about the performance issues associated with hitting a DB so much you might want to use a shared file system. A shared file system is a nice solution since the file system takes care of blocking I/O on individual files even when shared across a cluster. Further, these solutions are built to scale and don�t have any of the overhead associated with DBs.
Matt Liotta
President & CEO
Montara Software, Inc.
http://www.montarasoftware.com/
888-408-0900 x901
-----Original Message-----
From: Greg Nudelman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 04, 2003 6:45 PM
To: jdjlist
Subject: [jdjlist] RE: Caching of semi-static data across webapps
Yan, DB solution is not that bad! I heard of very successful set ups that put the entire application-specific info into a DB record that is read on start-up (like the XML config file, but this is instantly propagated to all of your 20 machines through the DB, your single point of contact). Ideally all your machines come up and read that record. To deploy your fix you can have a low priority thread that tries to check for any changes every 1-5 minutes via a time-stamp (better), or for an even more brutal approach, restart all your apps in sequence after the fix has been deployed (worse and will take longer then 5 minutes for 20 machines).
I like the JMS less, because it would take a lot of coding to set up this framework on our non-standard setup. If you got the standard J2EE system, then it sometimes comes pre-packaged. However, if it's a 1-time thing just for your cache, DB solution is arguably easier to build and test.
Greg the XP man is pushing his 2 cents.
-----Original Message-----
From: Yan, Hong [IT] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 3:14 PM
To: jdjlist
Subject: [jdjlist] RE: Caching of semi-static data across webapps
Thanks for suggestions. I can see using JMS is an elegant solution!
However, our project does not have JMS, and I do not expect the management
will approve the use of JMS only because of the messaging need to
synchronize the caches.
For this project, I have to find another alternative solution.
Thanks again.
Jeff
-----Original Message-----
From: Bill Wang [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 5:59 PM
To: jdjlist
Subject: [jdjlist] RE: Caching of semi-static data across webapps
I agree with Dave. Since you are using WebSphere app server, the JMS
solution is a better choice. You can use the publisher and subscriber
mechanism on a topic. You can have your webapps to subscribe with a topic.
Once one webapp triggers the load, it will notify a controller which
triggers your JMS to publish the latest translation to the topic. Whoever
subscribes the topic will get the lastest update. In your case, it will be
your cloned webapps.
Hope this helps.
"Dave Hanson" <[EMAIL PROTECTED]>on 03/04/2003 04:59:51 PM
Please respond to "jdjlist" <[EMAIL PROTECTED]>
To: "jdjlist" <[EMAIL PROTECTED]>
cc:
Subject: [jdjlist] RE: Caching of semi-static data across webapps
The requirement seems to be implementation of a notification method. The DB
solution, though a bit brute force, will work. A more elegant solution
would be to implement a permanent queue message via JMS on a subject. All
of the start-up servlets would populate from the database and block for a
message based on the subject. Once the correct message was received, the
database refresh could be accomplished.
Additional granularity could be added to limit the refresh based on message
content; i.e. only refresh the German translation.
J two cents added
-----Original Message-----
From: Yan, Hong [IT] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 4:29 PM
To: jdjlist
Subject: [jdjlist] Caching of semi-static data across webapps
James :
Thanks for sharing the ideas. As this is getting interesting, I would
like to explain what I do, and the problems that I have in more
detail :
I have a Singleton object that keeps several hashtables (with
Spanish/Chinese/Japanese/French/Germany texts and key strings for
these texts). These hashtables will be populated a start-up servlet
when the webapp starts. JSP pages retrieves the locale texts using
keys, so that the web system is translated in user's preferred
locale.
Let me take a simplified version, I have one WebSphere server with
three webapp clones in load balance. My server never stops, so when
translators need modify these locale texts, I need to reload the
corresponding hashtables.
The thing is, on a webapp based system, the translator can trigger a
reload, and this reload happens in only one of the clones, and the
other two clones are not refreshed. Users hitting these two clones
are still getting old translation.
In a word, in my system, the cached data is semi-static, and need to
be reloaded on demand.
Right now we are working on possible design approaches to fix this,
and we figure one of the followign may do the job:
(1) Use a database flag and let the Singleton object keeps on polling
this flag. Once flipped, the object will refresh the content.
(2) ...
But I assume this should be a common problem to any system with
multiple webapps in load balancing, and there should be a systematic
solution...Any suggestions are welcome.
Thanks
Jeff
-----Original Message-----
From: James Stauffer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 3:54 PM
To: jdjlist
Subject: [jdjlist] RE: Caching
We have a servlet that gathers the data about the caches and
serializes that info. One servlet connects to the other
servlets to get that info and consolidates it.
James Stauffer
-----Original Message-----
From: Yan, Hong [IT] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 2:02 PM
To: jdjlist
Subject: [jdjlist] RE: Caching
James:
Thanks for the post. I am also interested in caching objects
and right now I am having problems in refreshing them - I have
three WebSphere sites, each one of them has three webapp
clones.
How do you manage the caches across sites?
Thanks
Jeff
-----Original Message-----
From: James Stauffer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 2:48 PM
To: jdjlist
Subject: [jdjlist] RE: Caching
We have our own internally developed object cache. It
uses a hard cache (can't be GC'ed) extended by a soft
reference cache. It also has a cache manager servlet and
another servlet to manage the caches across machines. It
mostly only caches objects of the following:
public interface CacheAble {
public int getID();
public String getClassName();
public String getDescriptor();
}
If you are interested I can probably give more design
details.
James Stauffer
-----Original Message-----
From: Greg Nudelman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 12:56 PM
To: jdjlist
Subject: [jdjlist] Caching
We're have a home-grown Java application and would like
to introduce some kind of app-level cache manager. I'm
interested if someone has made anything like that --
shareware/custom packages, a study about the size of
objects in memory, anything like that.
All suggestions welcome. Thanks!
Greg
---
You are currently subscribed to jdjlist as:
[EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
http://www.sys-con.com/fusetalk ---
You are currently subscribed to jdjlist as:
[EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
http://www.sys-con.com/fusetalk
---
You are currently subscribed to jdjlist as:
[EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
http://www.sys-con.com/fusetalk ---
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
http://www.sys-con.com/fusetalk
---
You are currently subscribed to jdjlist as:
[EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
http://www.sys-con.com/fusetalk
---
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
http://www.sys-con.com/fusetalk
******************* PLEASE NOTE *******************
This E-Mail/telefax message and any documents accompanying this
transmission may contain privileged and/or confidential information
and is intended solely for the addressee(s) named above. If you are
not the intended addressee/recipient, you are hereby notified that
any use of, disclosure, copying, distribution, or reliance on the
contents of this E-Mail/telefax information is strictly prohibited
and may result in legal action against you. Please reply to the
sender advising of the error in transmission and immediately
delete/destroy the message and any accompanying documents. Thank
you.
---
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
http://www.sys-con.com/fusetalk
---
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
http://www.sys-con.com/fusetalk
---
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
http://www.sys-con.com/fusetalk
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
http://www.sys-con.com/fusetalk --
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
Meet Singles
