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
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.
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.
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.
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.
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.
Joined: Mar 19, 2006
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.
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.
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.
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5