Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

MultipleThreadModel disasters

 
frank davis
Ranch Hand
Posts: 1479
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We had a servlet that implemented MultipleThreadModel but had some disasters when multiple users started getting each other's data and transactions mixed up. We've gone back to SingleThreadModel but would like to try to get MultipleThreadModel to work. I think we need cache/pool the JDBC connections, but could someone comment on how that is done?
 
Tony Alicea
Desperado
Sheriff
Posts: 3226
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
MultipleThreadModel!?
 
Stephen Wei
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello:
I am new to Servlet/JSP, do not know much.
So now how do you judge weather to use MultiThreadModel or SingleThreadModel? I know for SingleThreadModel, I need to pool the servlet instances, and each request is served by one instance, not a thread. It seems to be easier to develop, because I do not need to write much synchronizing codes, but It says in my book that this approach is going to be very slow. Is it true?
How to decide which one is a better approach for a system?
Thanks.
 
Mike Curwen
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

one thing I'd be careful about is 'MultiThreadModel' because this is not mentioned in any spec I've read. There is such a thing as 'SingleThreadModel', but here is the thing to remember about servlets and the fact they are multi-threaded....

Just avoid using globals. ie: class variables. Even if your container sends two requests through your servlet at once.. ie: servlets are multi-thread enabled... the only 'synchronizing' issues you will need to worry about are on *class* variables.

Here's a big snip from the spec in case this thread helps others: the bolding (**) is mine:

[This message has been edited by Mike Curwen (edited October 16, 2001).]
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mike Curwen:
Just avoid using globals. ie: class variables.
And instance (=member) variables as well. Final variables should generally be fine though (unless the object they're referring to is not threadsafe itself).
- Peter
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18152
52
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While the SingleThreadModel interface lets the container know that the ENTIRE SERVLET (or JSP) must be serialized, the default is to run multithreaded. In that case, all the standard rules for multithreaded code apply - in particular, that no object of class scope should be accessed without suitable guards (synchronization).
Databases are an even stickier problem, since they may be modified outside of the Java environment, and thus you may need additional syncronization. Some of the things that you'd normally do:
1. Use database connection pools (lowers overhead)
2. Use transaction management
3. NEVER access modifiable class-wide or singleton objects directly. Always use synchronized methods.
Generally, you want to synchronize on a fairly fine level in order to reduce the amount of time the different threads run blocked. Don't overdo it though - synchronization has its own overhead.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic