On Thu, 27 Mar 2003, klute wrote:
> Date: Thu, 27 Mar 2003 09:10:55 -0800 (PST) > From: klute <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: RE: Threads in Servlet2.3 container > > Interesting.. What about the following scenario: > > say you have a base servlet that implements some > interface for your app. it has validate() and > forward() methods which encapsulates some logic used > by all servlets in your app. doGet() and doPost() are > different though. so, say my servlet A extends > MyBaseServlet... here are my questions: > > 1) is it a good idea at all: design your servlet-based > app by introducing a new hierarchy within a servlet > api. > Creating a new hierarchy is what pretty much any MVC based framework will do -- Struts, for example <http://jakarta.apache.org/struts>. Using subclassing to provide common basic behavior is also a very commonly used O-O design technique. (Struts, in particular, uses the style you describe all over the place, such as in form beans that have reset() and validate() methods with default behavior, but can be overridden by the app if needed). > 2) are there any thread safety issues that could be > introduced by this since MyBaseServlet will be > instantiated with every request as well? (note, > validate() returns a boolean. no class level variables > within any of the servlets (base or derived) are used) If you are not using SingleThreadModel (and you should NOT be, for reasons discussed ad nauseum in other threads), there is a *single* instance of your servlet class. Therefore, you *do* need to design your servlets to be aware that there can be multiple request processing threads active inside your servlet's doGet() or doPost() method at the same time. That's looking at things from the opposite perspective of the earlier comments about a particular request -- as we discusseed earlier, a single request will be completed on a single thread. Thread safety can be a complicated topic. The most important single rule is that you should use only local variables (declared inside a method) and not instance or static variables (declared at the class level) to store information that is specific to a particular request. Instance and static variables are shared across all of the simultaneous requests (since there is only one occurrence), so anything put there by request 1 is likely to get scribbled on by request 2 that is running at the same time. Why do local variables work? Because Java provides a separate call stack per thread, and that is where all your local variables go. There is a separate occurrence of the local variables per thread. You still have to watch out for thread safety when using sessions (it is more common than people think to have mutliple simultaneous requests accessing the same session at the same time), but the policy described above will help you avoid nearly all of the pain. > > > Thanks, > > James > http://www.freelancedeveloper.org Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
