This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
Hi All, Recently I read an interesting article on a particular Servlet design pattern. In this pattern, FrontServlet evaluates a request, and hands off the request to the appropriate RequestHandler (a common design as you probably know). Now, FrontServlet has an instance variable--a HashTable of registered RequestHandler objects. Because these RequestHandler objects are instance variables, will we run into concurrency issues?
For example, if multiple "login" requests come in, FrontServlet will hand off the request to its LoginHandler instance. The LoginHandler class itself does not have any instance variables, so I don't believe there will be concurrency issues, but I want to be sure this is a good design.
What do you guys think about this?
If you're interested, the article is here. [ October 26, 2004: Message edited by: Jeffrey Hunter ]
FrontServlet has an instance variable--a HashTable of registered RequestHandler objects. Because these RequestHandler objects are instance variables, will we run into concurrency issues?
Only if the servlet code outside of init modifies the hash table (why not HashMap?). If the hash table is set up in init and then is only read in the service code, there should be no contention issues.
I'd still say that it's a pattern to be avoided. I'd rather see the servlet store the hash in application context and reference it from there.
Thanks, Bear. Sorry so long to reply, but I've been swamped with a new project. <i>Hashtable</i>, yes, it was an old article I suppose. Anyhow, I've declared a synchronized HashMap as an instance variable, as its being used by the Dispatcher class exclusively. We'll see how it goes!