• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Threading issue with static variable

 
chets patel
Ranch Hand
Posts: 77
Eclipse IDE Redhat Tomcat Server
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a static map with all configuration data. When request comes to my application I read this map, retrieve some value and do further processing. I create a new thread for every request. Now If two request comes at the same time(even in miliseconds) and when I try to retrieve the value from the map, return value gets swapped.

For example--> below is the map
Key Value
A A1
B B1

If request comes for A and B at the same time, and If I try to retrieve the values from the map, returned value for A will be B1. Is it the possible scenario or some thing goes wrong in my logic.
Please help

Thanks in advance.

 
Divya Janyavula
Greenhorn
Posts: 19
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You need to synchronize the method/block of code which is accessing the map and fetching the value from the map
 
chets patel
Ranch Hand
Posts: 77
Eclipse IDE Redhat Tomcat Server
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is it occuring only becuase of synchronization??
 
S Thiyanesh
Ranch Hand
Posts: 142
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As per question, there seems to be some issue with application logic rather than thread sync.
1) If you are filling the map with static data for all the available values, and fetching the values for specific user, then it should not be dependent on the thread.
2) If there are user specific data to be dynamically loaded into the map for each request, then if you are using the same key, then the values will be overridden. If this is case, then you should change the way, the keys are mapped.

Please do post more about the problem if the issue is not clear.

Thanks
Thiyanesh
 
chets patel
Ranch Hand
Posts: 77
Eclipse IDE Redhat Tomcat Server
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Thiyanesh,
Thanks for your quick response.

1) Configuration file is loaded at application startup and stored in static map. For every request I get the key and retrieve the value from the map. If two requests are coming on the same time then for one request key other value is returned as I mentioned in my first post.

2) your second point is invalid as I am not loading any dynamic data.

Can you suggest more on this.

Thanks in advance.
Chetan



 
Mike Simmons
Ranch Hand
Posts: 3028
10
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, what exactly do you mean by a "static map"? Is there any reason to believe it's fully immutable, even after initialization? I'm guessing the answer is "no", though you probably believe it's "yes". Still, it's hard to give useful advice here without more information.
 
Shanky Sohar
Ranch Hand
Posts: 1051
Eclipse IDE Firefox Browser
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think Synchronization is a way to solve this problem and to iterate through a map with synchronization is a better way.
 
chets patel
Ranch Hand
Posts: 77
Eclipse IDE Redhat Tomcat Server
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Synchronization will slow down the performance...
what if I store this map in some application context and fetch it in local variable whenever required?



 
Chinna Eranna
Ranch Hand
Posts: 174
Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
chets patel wrote:
what if I store this map in some application context and fetch it in local variable whenever required?


That will not help unless you clone the complete map.

But I think, You need to look into your logic. Multiple threads reading a same map(assuming its not being muted at run time) will not cause this problem.


 
S Thiyanesh
Ranch Hand
Posts: 142
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Its a synchronization issue due to race condition.

Scenario in following sequence could have resulted in incorrect behavior.
1) Request from "A" for the key "A"(first thread)
2) Fetch the value for the key "A" and store in a variable.
3) Request from "B" for the key "B" (second thread)
4) Fetch the value for the key "B" and updates the same variable used to store the value of "A"
5) Return the value stored in the variable for the call for A(actual value is that of the "B")
6) Return the value stored in the variable for the call for B

If you have this logic, then you need to use synchronized.
 
Chinna Eranna
Ranch Hand
Posts: 174
Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
S Thiyanesh wrote:Its a synchronization issue due to race condition.
................
If you have this logic, then you need to use synchronized.


That is true only in the case, when the variable is shared between threads.
If the variable is local to a method, it is not the reason.

Chets, You need to show your logic, that you are following to get the values from map.

 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


i) really need to see that code ...
ii) you need to consider visibility as well as synchronisation (if you don't know what that means you really need sync), if do have multiple threads and sounds like you do even if one is just the initial creator.

iii) Consider using ConcurrentHashMap its very efficient at not blocking access ...

ConcurrentHashMap

If your at all unsure if you need it use it.

Retrieval operations (including get) generally do not block, so may overlap with update operations (including put and remove). Retrievals reflect the results of the most recently completed update operations holding upon their onset.


Writes are also not necessarily confined to one thread at a time

The allowed concurrency among update operations is guided by the optional concurrencyLevel constructor argument (default 16), which is used as a hint for internal sizing. The table is internally partitioned to try to permit the indicated number of concurrent updates without contention.

 
suraj aryan
Greenhorn
Posts: 24
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The values should not get swapped even if it is synchronization issue .
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic