The issue here is performance. If you go ahead with the synchronization approach then it'll probably create a bottle-neck there because no matter what only one thread can run the doGet() at any instant of time. Generally speaking, if the doGet() have a lot of things to do, it's good design to synchronize only those code blocks within the doGet() that cause non-deterministic behavior so as to mitigate the performance problem as much as poosible. If your server can take high loading, it may be better, by using the SingleThreadModel approach, to create a pool of servlet instances so as to allow processing requests in parallel.
You can but it will be a performance hog. If you implement SingleThreadModel, the container runs only one thread in the service method, but to service multiple requests parallelly, the container is free to instantiate multiple instances of your servlet class. If, instead of implementing SingleThreadModel interface, you synchronize your doXXX methods, you will get the worst of both worlds. Neither the requests will be served parallelly (because of synchronized) and nor the container will be free to instatiate multiple objects (because of not implementing STM). Of course, in some cases, this is what you might want! HTH, Paul. ------------------ SCJP2, SCWCD Resources, Free Question A Day, Mock Exam Results and More! www.jdiscuss.com Get Certified, Guaranteed! JQPlus - For SCJP2 JWebPlus - For SCWCD JDevPlus - For SCJD