Hey out there,
So I have a complex screen where there are nested lines within lines. I used several HashMaps to handle all this. All is well but QA noticed a fun bug Friday. One user in this screen sometimes would get the others data. oops! Will changing hashmaps to concurrentHashMaps fix this? I assume this is the issue. Thoughts/tips are appreciated.
Hmm yeah. It's "fun" bug alright, if you consider staying up late night trying to solve hard to reproduce concurrency issues and possible lawsuit against your employer because you showed data meant for employees of Client A to employees of client B as "fun". Yippee! hard work and financial ruin
This kind of problem is usually a result of a concurrency problem. You have the Hashmap shared between 2 threads, and while one thread is updating the hashmap, another one is reading it. Using ConcurrentHashMap might have solved the problem or might not have. It might have just changed something so that the problem will appear later. You might want to post the code so someone can look at it.
You might want to consider changing your code so you don't have a hashmap shared between threads in the first place.
Joined: Feb 15, 2012
hmm so I narrowed down my problem
My problem is when user A finds invoice A and user B finds invoice B. Then user A saves invoice A. User B goes to "find" and now has Invoice A displayed on thier screen.
So What approach should I take in solving this? Performance is an issue so I dont want to lock the viewModel object. IS this an instantiation issue or a concurrency issue? And if so what should I look at for reading as to resolve this?thanks
I would have to start by finding out what these "screens" are and how more than one user is able to use them. (Of course you already know that, but nobody else out here does.) I expect the end result is going to be that you find some object which is shared between two (or more) threads and which contain some kind of permanent state which is shared among the threads. It's possible that the solution will simply be to give each thread their own instance of that object instead of making them share. But again this is all speculation because we don't know anything about your system.
Right, more or less speculation, but IME, it's a singleton object that is sharing "state" between threads. Let's say you have something like this
Now here InvoiceService is a singleton. It creates one and only one instance of InvoiceDAO. SO, in effect InvoiceDAO becomes a singleton, since there is one instance of InvoiceDAO that is being shared between threads InvoiceDAO keeps the invoice in a data member that is shared between threads. In other words, it keeps information that is relevant to a particular request (state) in a variable that can be accessed by any other thread. So, if one thread calls saveInvoice, and another calls getInvoice, both try to change the same variable inside InvoiceDAO at the same time, which causes a concurrency issue. The first thing you need to do is look for cases like these where state is shared
Once you narrow down your problem, there are multiple ways you can solve this. The best way is not to keep state in shared variables. Ideally your code should be like this