Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
1- In general I declare all my member variables "private" and then create public "getter" and "setter" methods to get and set the values respectively. Will I have to declare all these "getters" and "setters" "synchronized" (for threading) and the member variables "volatile" (so that the threads handle the variables correctly) ?
2- One of the reasons I'm asking is: from what I've read, synchronizing methods can decrease performance big time ?
I didn't use "volatile" throughout my application. All my public methods in the Data class are "synchronized", so my Data class is thread-safe. But as you pointed out in your last remark: this approach is not that performant, but this approach is very easy (no synchronization blocks you have to use etc.) and an easy approach is preferred to a more performant one.
Sometime prior to JDK 1.4 synchronization caused some pretty hefty performance loss. By the time of JDK 1.4 it was almost a non-issue. These days (and you can test this yourself) making something synchronized has so little effect on performance that you can effectively discount it.
What can cause a performance hit is contention for resources. This issue is the same whether the resource in question is a synchronized block, accessing a single socket, using a single file descriptor, or placing all your SQL code inside transactions. If all clients are going to get blocked around a single resource then the application as a whole will suffer.
Therefore whenever you make a distributed application you should consider how you can reduce contention for single objects. Ebay actually make a case for removing all transactions from their calls to the database. (!) In our case, it makes sense to reduce the synchronized code to the smallest logical blocks possible. You rarely need an entire method synchronized. The usual use-case I see is when somebody synchronizes the lock method. But even there it can make sense to synchronize on a different mutex rather than the Data class.
One of the questions you should be asking yourself around about now is: exactly what do you have that could potentially be changing that you would need to make atomic? There should really only be one or two objects that are shared between clients that are variable. The object holding the locks is one. The file descriptor is potentially another. Any others?
Thanks man, I really do appreciate your (and everyone else') feedback!
You know what; I actually got myself so worked up after reading through loads and loads of these Topics on Friday night, that I started to feel quite intimidated by some of the guys' code snippets. I actually just stopped that for now, and is focusing on what I need to do and do it the way that I would do it - and of course ask the necessary questions as soon as I get stuck.
Thanks, I have read through the information from the links you've provided!
Enjoy the evening and speak to you soon.
I need a new interior decorator. This tiny ad just painted every room in my house purple.
Free, earth friendly heat - from the CodeRanch trailboss