SCJP 1.4 100%
SCJD 99.5%
The GUI will only permit a client to perform a single action at any one time, so therefore, in the above scenario, Client A would not be able to perform any other operation until the current request has completed. Effectively this approach will ensure that a client will not be able to lock the same record twice from the GUI.
SCJP 1.4 100%
SCJD 99.5%
I also added a javadoc section about how multiple locks should be acquired in the order of the recNos, in order to avoid other types of deadlocks.
SCJP 1.4 100%
SCJD 99.5%
Your mind should be set as if somebody else might use your classes, maybe later, and maybe even outside the current project.
Accept this point and just to clarify.... however we can't detect this scenario either with the provided interface, and as with the previous case, need to document it .... with words to the effect that the user of the data class has to ensure that it ONLY locks one record at any one time, failing to adhere to this may result in a deadlock situation. Is this about right ?(X locked rec A and tries to lock B, while Y locked rec B and tries to lock A).
SCJP 1.4 100%
SCJD 99.5%
Don't get me started about those stupid light bulbs. |