I'm working on large web application which has got number of configuration parameters, i.e NO_OF_PRODUCTS_ON_SEARCH_SCREEN = 5. Currently this parameters are in one Parameters.java file(statically loaded) and all action/ejb/jsp uses this .java file for usage.
Now ,as parameters do change frequently on client request, I have added all those to parameters to DB with creating proper schema. Lots of action/jsp/ejb uses this parameters(Let's say one web request uses 10 parameters) and If every time I make a DB request to lookup parameter it kills my performance so I have introduced caching between action/ejb/jsp and DB.I have used EHCache here and on lookup from acton/ejb/jsp goes to cache and cache result is returned if it's cached otherwise explicit DB request is made.
My application is in clustered environment and has got more than one server so I will have either go with 'cache replication' or 'share a cache'
Question 1 : If I am going to share cache , Is Symbolic link good solution? Question 2 : What are the possible caching solution which has got this capability of replication in clustered environment. So far , I have explored EHcache , JCS and JBoss cache but need some more views (which is better,stable , faster for replication) to gain good performance in web-application.
Any views for above scenario or answers for questions would be great help.
[ January 06, 2008: Message edited by: vishalraju shah ] [ January 06, 2008: Message edited by: vishalraju shah ]
SCJP1.4 (92%), SCWCD (85%), SCBCD (81%), SCEA-I (In Progress)
We are using ehCache in clustered environment (GlassFish). Our current requirement is fully covered by its performance and provided features.
We use it in asynchronous mode but if you have high rate of changes and high rate of requests which must use latest values then you will need to use synchronous mode replication which will introduce some delay in your response time.
PS, sharing one cache can reduce your network load but introduce a bottleneck and a single point which can bring your system down when it goes down.