This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I follow instructions on the book to run the threadSafety.jsp
1. open two browser window 2. URL http://localhost:8080/chapter11/threadSafety.jsp the result sequence on browser windows, 1 3 5 7 9 11 13 15 17 19 and 0 2 4 6 8 10 12 14 16 18 which makes sense to me as isThreadSafe set to true. I change the isThreadSafe to false then re-run this jsp. I was expecting the result to be 0 1 2 3 4 5 6 7 8 9 on both browser window as these two threads does not share the j variable. To my surprise, the result is the same as isThreadSafe set to true. Can some one help me figure this out ?
not so smart guy still curious to learn new stuff every now and then
The SCWCD Exam Study Guide has the same example on page 195, it says that setting isThreadSafe="false" is equivalent to implementing SingleThreadModel. If I understand this right the jvm creates an instance of the servlet, the A-thread starts to process it, first it prints, then increments, and lastly sleeps. As A-thread is sleeping the second request comes along and uses any available instances form the pool. Our current instance is available because the previous A-thread is now sleeping on it and doesn't have a lock on it. So B-thread uses the one instance to print, increment, and sleep, giving the instance up back to the jvm. A-thread wakes up gets the instance and starts all over. Bottomline, both threads are sharing the same instance from the pool. The numbers would probably get really weird looking if you had several threads running against several instances as the jvm gave you an instance out of the pool. This doesn't seem right to me either and wonder about it still. If you add the synchronized(this) line to your code like this:
Then it maintains the lock on the instance until it is finished processing it and prints 0,1,2,3,4,5,6,7,8,9 in one and 10,11,12,13,14,15,16,17,18,19 in the other [ May 14, 2003: Message edited by: John Hembree ]
Joined: Aug 24, 2001
John, Thanks for the response, it helps me better understand this issue.
quote: john Bottomline, both threads are sharing the same instance from the pool. The numbers would probably get really weird looking if you had several threads running against several instances as the jvm gave you an instance out of the pool. Dear friends, I don't think ,when implementing SingleThreadModel two threads can execute methods of 1 instance (servlet) at the same time,anyway in the given situation the server either creates a pool of different instances of the same servlet or the server does'nt create a pool of instances, and uses only one instance and lets only one thread to execute its methods (" one thread at a time." it does'nt mattter even if the first thread has taken sleeping pills ,the second thread will have to wait!) I think i know what's happening here,i will let u know as soon as i confirm it. 'Don't worry,be Happy' Amer have a look at this one [ May 17, 2003: Message edited by: Amer Khan ]
<i>Dare to dream - everything that exists today,was once a figment of someone's imagination, nobody says tomorrow can't be a figment of your today.</i>
The reason I think multiple threads are running on it, is because if you open up three browsers and point them to the threadsafety.jsp it takes about 11-12 seconds for the all three browsers to finish processing. Which illustrates that they are running in parallel. So I can't see a single thread sleeping and running for the other browser requests at the same time. When you add the synchronized block it takes 30 seconds because they get in line for the servlet and are serial. Which wouldn't matter if it was a single thread or multiple threads trying to access the servlet. But please feel free to figure it out and post here, I would like to know for sure.