Hi Gurus,
I see some race condition in my application. And my question ist now. If I use:
synchronized(session)
{
}
in one servlet. Does is prevent an other servlet (not another instance of the same servlet) to manipulate the session? (second servlet doesen't use synchronized(session) )
I thought this isn't possible but I realise this is the case in my webapp.
Okay so how does
Object o = session.getAttribute("MyObject");
synchronize(o){
... something
}
differ from
synchronize(session){
... something
}
and why can I not sychronize on the session Object lock?
well, with synchronize(session) you磖e locking the whole session and with synchronize(obj) you磖e locking the obj object but not the session.
If you lock the session object you prevent that another servlet use it, so that servlet cannot use the getAttribute() method.
Elsewhere when you lock the obj object the session is "free" and another servlet can use it. This Improves the performance of the web application.
I hope to have been clear. :)
Regards
Gabriel Garc韆.
As I know session may be serialized to persistance storage between requests and there is no gurantee that you are using the the same object in different requests so synchronized modificator doesn't suits in common case. You may use it only with particular webcontainer and only if you know HttpSession implementation details.
Hope this helps
No that doesn't help.
"there is no gurantee that you are using the the same object in different requests "
Session objects are on a per user basis.
Scenario One: User1 makes request. Servlet synchronizes on the Session object for this user. All other requests for other users use different Session objects so are not impacted by the synchronization for user1's Session. Servlet releases lock on user1' s session and returns the response.
Scenario Two: User1 makes request. Servlet synchronizes on the Session object for this user. All other requests for other users use different Session objects so are not impacted by the synchronization for user1's Session. Before the server releases the lock on user1's Session object, user1 makes a new request which tries to access user1's Session object and is blocked until the first request is processed and the lock released.
I don't see how in either of these two scenarios that useri could get two different Session objects. In fact if it were possible then the storing of data in sessions would not be guaranteed which would be amajor flaw in the whole technology.
