Originally posted by oli renard:
The recordLockManager is a static reference to an instance of a class called RecordLockManager that locks and unlocks records on the database. In that sense, I do not even call the lock or unlock methods in the Data class as these are taking place at a "higher" (business-tier) level.
I think the lock and unlock methods that are given in the given interface should be used in the locking mechanism. I mean if you don't use them, then all you are using from the provided interface are "update" to book a record and maybe "find" to search. Its just my opinion. Some ranchers even thought(and discussed this issue in detail some time back) that as the lock/unlock methods are made public, they must be exposed to client. I think you should wait for other's opinion this who already took the exam. What I don't understand is how are you using locking mechanism in the business layer without involving the lock/unlock methods from the Data? Oh I think in B&S assignment there are no cookies involved. So your locking mechanism would be completely different than mine(URLyBird).
Note also that the RecordLockManager can lock and unlock records in a thread-safe fashion as all its methods include sinchronization around a static reference to a HashMap.
My understanding of the application is also that when the RMI server is started, there is effectively only 1 instance of the Data class on the server.
If there is no connection factory, then only single instance of the class which you registered in RMIRegistry is present. So all the requests will eventually get a single reference to your Remote interface to use.
Can someone please help me determine whether my design is both thread-safe and correct?
You definitely want to make sure that IF a client was able to use your Data class exclusively it would be thread safe for multiple clients.