Hi HaoZhe,
Welcome to JavaRanch.
Whether you use Sockets or RMI should have no bearing on your locking code.
What the locking could should do is
logically stop two clients from modifying a record at the same time. A client must obtain the lock before it can modify the record, and only one client may own the lock for any given record at any given time.
does it mean if client A booked a ticket than client b cannot book it
Yes.
Since only one client can own the lock for a particular record at any given time, when a client obtains a lock, it can then verify if the record is still available to be booked. This will stop the situation where client b overwrites the booking made by client a.
or if client A is dealing with record 1 client B cannot access record 1?
That is up to you. Stopping any other clients from being able to read the data until after you have released the lock gives very little value (IMHO), so I wouldn't bother with it.
If you wrote your application so that the client could change their mind before finalising the transaction (effectively a commit / rollback handler) then being able to block reading would give you your first level of isolation - preventing dirty reads. However I think that this is far more than we need to worry about for this assignment.
Regards, Andrew
