Remy Maucherat wrote: > On 1/6/06, Michael Echerer <[EMAIL PROTECTED]> wrote: > >>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. > > > Nice, but completely wrong. STM in Tomcat uses an instance pool which > allows having a minimal impact (something like 5%), and it will > perform much better than syncing, unless the said sync is trivial.
Completely wrong? Actually taken from servlet spec 2.5 draft, but I guess it's not changed since 2.4. "SRV.2.2.1 Note About The Single Thread Model The use of the SingleThreadModel interface guarantees that only one thread at a time will execute in a given servlet instance’s service method. It is important to note that this guarantee only applies to each servlet instance, since the container may choose to pool such objects. Objects that are accessible to more than one servlet instance at a time, such as instances of HttpSession, may be available at any particular time to multiple servlets, including those that implement SingleThreadModel. It is recommended that a developer take other means to resolve those issues instead of implementing this interface, such as avoiding the usage of an instance variable or synchronizing the block of the code accessing those resources. The SingleThreadModel Interface is deprecated in this version of the specification." Probably I mis-understood what "guarantee only applies to 'each' servlet instance, since the container may choose to pool such objects". In how far this is good for performance reasons, I cannot judge, never tried for above reasons. > > The reason this is deprecated is because some people thought it would > solve all their syncing problems, while it doesn't address many things > (like session access). true indeed, that's why I warned to use single thread model for an easy cure for all multithreading issues (especially if a DB access is intendend). Cheers, Michael > > -- > xxxxxxxxxxxxxxxxxxxxxxxxx > Rémy Maucherat > Developer & Consultant > JBoss Group (Europe) SàRL > xxxxxxxxxxxxxxxxxxxxxxxxx > > --------------------------------------------------------------------- > 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]
