HttpServlet is inherently thread-safe as long as you don't use any instance and class variables in your code. There is also no need to sync around the session object, because there is only one servlet that is active at a time. The only sync you have to do is with app context objects.
If you want to sync on your DB resource, you will have bottleneck problems with DB connections. The best solution is to use a DB connection pool which is more scalable. ND -----Original Message----- From: Michael Echerer [mailto:[EMAIL PROTECTED] Sent: Friday, January 06, 2006 11:52 AM To: Tomcat Users List Subject: Re: Single Thread is deprecated? Christian Stalp wrote: > Hello out there, > I want to build a servelt which access a database. To avoid > race-conditions and to realize synchronous access, I decited to make a > "Singe Thread" Servlet. But Eclipse told me that this is no longer a > usable code. Usually the best solution is to synchronize just the part that accesses the single resource (the DB) instead of using single thread. In worst case you won't even achieve what you want using single thread mode because according to the servlet specification servlet containers are free to pool servlets, if it implements SingleThreadModel. Hence you could have multiple pooled instances that be no means guarantee an synchronized access to your database in case of simultaneous requests hitting different instances. So SingleThreadModel is deprecated for good reason, since servlet spec 2.4 and also for 2.5. You are better of synchronizing yourself. Don't rely on SingleThreadModel as an easy way to get around multithreading issues. In case you have different code parts accessing your DB or various clients, it might not even help to just sync one servlet. You might even have to set database transaction isolation level to fit your needs for your DB connections. Most DBs have "read-committed" by default, but it might be that you need isolation level up to "synchronized". Depends on your use case... Cheers Michael > > So what can I do else? > > Thank you... > > Gruss Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
