This week's book giveaway is in the Java in General forum.
We're giving away four copies of Think Java: How to Think Like a Computer Scientist and have Allen B. Downey & Chris Mayfield on-line!
See this thread for details.
Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Fun bug I found in my new screen.

 
steve kelly
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jayesh A Lalwani
Rancher
Posts: 2756
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
steve kelly
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Paul Clapham
Sheriff
Posts: 21107
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jayesh A Lalwani
Rancher
Posts: 2756
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic