Hi Jianhua,
Having your book() method on the client side does not guarantee thread safety on the server side. Your client's book() method is still going to call the server's modify() method. And since you can have two separate clients running simultaneously, that means that two separate threads can run on the server side simultaneously, both calling the modify() method. The modify() method calls seek() and then calls write() - imagine what would happen if this method was not thread safe: one thread could call seek, then the next thread could call seek, then the first thread could call write (which would overwrite the wrong record), then the other thread could call write which would also overwrite the wrong record.
Now the provided Data.modify() method is already thread safe: only one thread can call it at any given time. But you have to create a couple of methods in the Data class yourself, plus you have to create a few classes for the server. You need to consider whether any of them need to be made thread safe, and what needs to happen in order to achieve that.
Problem is booking method involves several database operations, lock/read/modify/write/unlock, but remote database server's modify(), and write() already contain lock/process/unlock logic
Rewind a step.
Your client is calling the server's lock(), read(), modify(), and unlock() methods.
So why would your server's modify() method also call lock() and unlock()? As you yourself noted, this is going to result in locking occuring in two places, and would require some sort of reentrancy.
Personally I think that your server's modify() method should just verify that the current client does own the lock on the record, and throw a DatabaseException (or a subclass of DatabaseException
) if the record is not locked.
Regards, Andrew