As far as i know if isThreadSafe="true" then it means that that the page is Unsynchronized, so to make it synchronized either write isThreadSafe="false" or make the block synchronized
posted 12 years ago
Originally posted by Gaurav Chhabras: As far as i know if isThreadSafe="true" then it means that that the page is Unsynchronized, so to make it synchronized either write isThreadSafe="false" or make the block synchronized
Rathi, There is no problem with you refering to a book. The problem is that you're quoting too small a sample from the text for us to be able to understand what's going on.
I'm guessing that the text, somewhere on that page or one of the adjacent pages explains why they're using synchronization. We don't know what the bean is doing, what scope it's in, etc..
Assume that nobody here owns that book. Even if someone does and is able to help you by reading the full text, neither the question nor the answer are going to make sense to anyone else in this public forum.
Can you explain to us what it is that the example is doing?
Where it's machine generated code, my guess is that it's probably not necessary to synchronize if the object is going into request scope.
Since the useBean tag can also create objects and bind them to session and context scope, it makes sense that it would synchronize access to the object while checking for, creating, and binding objects to it.
Let's assume, for the sake of discussion, that the scope is context. The book gave you a good hint:
Picture if, in your request, the JRE looked for the object in context scope and didn't find it. It would then create it and try to bind it to context scope. Now, picture if, in between checking for and creating the bean, someone else's request binds another instance of that bean to context scope. You now have a threading problem.
The same thing could happen with session scope.
Again, it probably wasn't necessary to synchronize for request scope but it also doesn't do any harm since there will only be one thread ever trying to bind the bean to request anyway.
Im going through HD & JM's SCWCD book and came across a similiar example of code...according to them requests are typically thread safe, but they can become unsafe if the developer tries to create threads that access the request object in the doGET/POST() methods.