The link you've provided in the previous message had a strong impact on the way I intend to design. The thread was long, it took a lot to read but it worth it. I have no intention to go into details, I just want to say that my design fits in the 3-tier archiecture category. In other words, I consider myself part of the "Guinea pigs" team
. While I understand your design I appreciate your determination to stick with the specs, I consider it not the best way to go.
Since in any design the client needs to make clear specs amd in this case the client is not to be found, I consider that he declined the invitation to discuss the details of the requirements.
In this case I take a decision based on my professional expertise.
So as I understand this, your Data.update() method calls Data.lock() itself. In which case there is no value in Data.lock() being public. (But it has to be, since that is the signature in the interface - why do they have such an method signature then?)
My Data.update() calls indeed Data.lock() but the latter only dispatches to the lock() method of the LockManager class. It is this class that handles all the locking process and every instance of Data has a reference to it.
Client 1 believes that they have booked this Contractor and paid their money. Client 2 believes that they have booked this Contractor and paid their money.
Not exactly, at reentrancy each thread checks for deletion and for the booking status. This cannot happen.
What can happen (and my current design doesn't cover this yet) is that a client/CSRep modifies the name, location and other fields of a record while another one waits to re-enter. Since I only check for deletion and booking, the client might book a contractor that moved to a different location. I'll think about this.
I'm sure that whatever design will choose, we'll meet at the other side.
Phil, you've made an excellent case in that thread.