LIFE happens, but you always play a part in what happened.
Yevgeni Duvenage wrote:
I did consider your point before, and after I posted the code you saw, I actually swapped the order of code to add to and overwrite balance and perform the delay. It made no difference.
Dave Tolls wrote:As it stands, the browser of the second request will be waiting for the response to come back, which won't happen until the other thread has released its lock and handed over to the paused thread.
As for what you want to happen, I'm not sure I understand what you are trying to achieve.
Stephan van Hulst wrote:
Dave Tolls wrote:As it stands, the browser of the second request will be waiting for the response to come back, which won't happen until the other thread has released its lock and handed over to the paused thread.
This is what Yevgeni wants to happen. It's not happening.
Stephan van Hulst wrote:
As for what you want to happen, I'm not sure I understand what you are trying to achieve.
The exercise is to see that using synchronization to make servlets thread-safe is a bad idea, because it introduces a lot of latency. The next exercise will show that making servlets stateless is much better.
Stephan van Hulst wrote:Because if there wasn't a shared balance, there would be no point in synchronizing the methods.
Yevgeni Duvenage wrote:Firstly, Stephan says I am not locking on the servlet, while Dave says I am locking on the servlet. Contradiction here, so am I or am I not?
Yevgeni Duvenage wrote:I read the article. It points out that (for some reason) if one method that is synchronized, is being locked for use by some thread, then all other methods that are coded as synchronized are locked as well. That does not make sense to me, why would the program only be able to run one method at a time instead of being able to run any of its methods, depending on what simultaneous threads require?