I implemented a separate lock manager class that allows Insert Row Locking (IRL) so that if two or more clients attempt to perform the sequence lock-read/modify/write-unlock concurrently, both modification attempts will be handled correctly. The lock manager class provides consistent and concurrent access to data in a multi-user environment (RMI). Because IRL is necessary only in remote mode, not in local mode, it makes better sense to implement it as a separate lock manager class. Locks prevent simultaneous updates of the same row of data. With a separate lock manager, only one user at a time can update/create/delete a row of data. So while one user is booking a subcontractor, another user cannot modify the same row record. Without a good lock manager, users could overwrite each other booking, giving the impression that someone can book the same contractor to more than one person.
The row is locked by a given client cookie. Since I'm using RMI remote access, the user will be assigned a random thread each time when it accesses the server. The application is not guarantee on the same thread so thread reference is not able to use. I created a client cookie class to generate a cookie automatically when the user starts the client's applications. The odds is 2 to the power 31 is nearly 0. It is impossible for two clients assigned the same cookie. The responsibility for record locking is kept in the DataLockManager. Always make sure the specific record is lock free before locking to prevent dead lock issue. If the specific is locked by another client, it will wait until the lock is released.