Duan, Nick wrote: > 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. How can you guarantee that only one servlet is active at a time? Tomcat by default has many connector threads that could simultaneously handle concurrent requests to the same servlet or different servlets that all could work with the same sessionid session objects. Without SingleThreadModel this servlet won't be pooled, hence all requests would have to be serialized to make this work, which is obviously not an option for performance reasons as the spec says (e.g. regarding servlet lifecycle and synchronized service methods) BTW, if only one servlet would be active at a time, your advice not to use instance/class variables would not be of any use, as under this assumption no concurrency issues while accessing those variables could occur. However it's valid. It should be quite easy to write a simple test jsp using a session and containing e.g. image links to a servlet that manipulates session content, each time called. Due to most browsers behaviour to request many images at the same time and Tomcats connector threads, I wouldn't bet on this, if you put this under load and log results... > > 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. > DB connections pools are a good idea (e.g. to avoid connection opening times that take a few hundred ms with most DBs, eventhough neglectable for others). Nevertheless depending on the kind of transactions done, setting an appropriate transaction isolation level is just as important as doing other syncs. If you just read from the DB you can stick to the default level, but e.g. for a booking & reservation system, I wouldn't trust read-committed, when doing lookups, inserts, updates wildly mixed in one transaction. Could easily happen that someone else booked your trip then, eventhough you got the confirmation... ;-)
Cheers, Michael > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
