singlethreadmodel vs. synchronize

java-programmer, singlethreadmodel vs. synchronize I have a book that is explaining servlets and implements
singlethreadmodel instead of using synchronize with wait and notify.
does that only work with servlets? which is better?

java-programmer >> singlethreadmodel vs. synchronize Ryan Gaffuri wrote:
> I have a book that is explaining servlets and implements
> singlethreadmodel instead of using synchronize with wait and notify.
> does that only work with servlets? which is better?

They don't even solve the same problem. SingleThreadModel is *not* a
solution to having multiple simultaneous requests modify shared state.
All it does is guarantee that a new instance of the servlet will be
instantiated for each simultaneous request, rather than running the
requests on the same instance of Servlet. It's a matter of convenience
-- if you want to store a lot of per-request state so it can be accessed
throughout the implementation, SingleThreadModel lets you use instance
fields for that purpose.

SingleThreadModel is also universally considered a bad idea.
Performance is often cited as the reason, but in reality it's because
any situation where SingleThreadModel helps is an indication that you've
failed to do proper OO design and are avoiding encapsulation.

If you need multiple simultaneous requests to share state, then you need
to use 'synchronized' regardless of whether you've used
SingleThreadModel or not. The wait/notify mechanism may also be useful,
depending on your specific concurrency requirements.

As for whether it only works with servlets, the answer is that outside
of a servlet environment no such general mechanism exists. If you have
a specific non-servlet environment in mind, then a similar mechanism may
exist... but you'd need to say what environment that is before anyone
could help you.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation