Actually, any class with only local variables is always thread safe. On 1/6/06, Michael Echerer <[EMAIL PROTECTED]> wrote: > > 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] > >
-- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
