wood burning stoves 2.0*
The moose likes Servlets and the fly likes Synchronization of ServletContext Object. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Synchronization of ServletContext Object." Watch "Synchronization of ServletContext Object." New topic
Author

Synchronization of ServletContext Object.

john kerl
Greenhorn

Joined: Jul 29, 2011
Posts: 13
Hi All,

-- I am trying to make the ServletContext synchronize because when 2 or more clients, are trying to modify the same servletcontext attributes, then that will be a problem. Because Servlet A tries to set context attribute as context.setAttribute("A","test1"); and Servlet B tries to set context attribute as context.setAttribute("A","B related code"); It could happen because Servlet B doesn't know that Servlet A also has the same attribute. That will be a problem as now servlet A will get the output as "B related Code" instead of "test1" if both acces the same code at a time, and Servlet B changes before servlet A recieves the response

--If clientA write synchronize(getServletContext()) and in that he sets 2 attributes context.set("A","test1") and context.set("B", "test2"), clientA first gets the lock on the ServletContext object.
--But another person (clientB) from another servlet also try to access the synchronize(getServletContext()) method and try to replace the values of the attributes "A" and "B" when clientA's lock is still there.
Will clientB can access it...? I think no, because clientA has already lock.
-- Now my question is, will clientB will able to run his Servlet or any other client can run their servlets, on the same context , as clientA has already a lock on contextobject. And for the servlet to run, the servlet should be on running on that context itself and since the lock has already been obtained for that context, how can other client requests be servered for anyting ( I meant not only for the attributes but any other code in it), until clientA releases the lock ?

NOTE: I think that getServletContext() will return the same context reference always instead of creating with the "new" operator each time. i.e, singleton object.

Please clarify me regarding this..!
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12803
    
    5
It looks like you are trying to use ServletContext for user specific data - this is completely contrary to the whole idea of the javax.servlet.ServletContext interface.

Is there any reason you can't use the normal approach of keeping user specific data in a session or a database?

Bill
john kerl
Greenhorn

Joined: Jul 29, 2011
Posts: 13
William,

I got through this scenario when I was making some R & D. So I am looking for the clarification, on how to proceed if we are in this type of scenario. Ofcourse, we can go with request, session or any properties file or database. But I am looking into this direction.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61420
    
  67

john kerl wrote:But I am looking into this direction.

Why? As pointed out, "this direction" is inappropriate and a misuse of the tool.

It's like saying "I know I should be using a saw to cut this board, but I want to use this tomato plant instead."



[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Sujata Samal
Greenhorn

Joined: Jan 29, 2008
Posts: 20
John,

Once a thread gets a lock on an object then other threads cannt use the synchronized(only) members of that object .So here in this scenario ofcourse yes clientB cannt use setAttribute() until clientA releases the lock on servletcontext but clientB can use the servlet context's other non-sync members.

Hope this helps.

-Sujata
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Synchronization of ServletContext Object.