Hi, I am currently doing the UrlyBird developer project also, and have nearly completed it (user guide, choices, javadoc and unit testing to go). Here's some of my thoughts on your points.
1. I have assumed the same thing, that automated tests get run against the Data class. From what I've read, these tests are run before your actual programs are even tried out. For this reason, the DBMain interface should be all thats implemented for the public interface of your Data class, nothing more. For your testing you should write similar unit test cases to exercise your Data.java (that are separate from your server code).
2. Only lock the db via the lock/unlock/isLocked methods. Putting locking inside the CRUD methods turns it from being an interface to the database to having business behaviour. The reasoning behind this is that the javadoc for these CRUD methods does not mention locking, and it doesnt allow people using the code to choose the locking strategy/isolation levels to use for a database.
3. No, the client app only allows changing the owner field of a row. Creation and deletion is not required through the client. Creation and Deletion need to be only implemented in the Data class. I assume that the marker will use an automated program to populate the database with data to use when they are testing your client, using the methods in your Data class.
4. For RMIRegistry it is easier to just get your startup code for the server to look for a registry and start one up if none is running. Then check that a URLyBird server is not in the registry, and if so bind your server instance to the registry. This is only a few lines of code to do. It is best to make things as easy as possible for the marker - think of them as a customer using your app - it should be simple to run.
5. Yes. I've used these as identifiers for a room in the database, as they are unique. Its probably up to you whether you use them or not. I assumed that there could be more than one room at the same hotel available through the application, so there was no other way of uniquely identifying a record.
6. Not sure what you mean about reserved records. In my implementation, the only deleted records are ones specifically marked as deleted. All data is in the past in my DB, but they are still valid records in the database. They can still be searched for by my client. They just cannot be booked by the client due to the 48 hour rule. In a full, real-world server implementation there would be a background job that deletes these records as they expire.
1. I didn't make it a singleton. I have a business model class (BusinessServiceModel) that implements the business rules of the server and talks to the Data class. The Remote service (RMI) impl has an instance of this BusinessServiceModel to service any calls from clients. As there is only ever one instance of a remote server in the registry, there will only ever be one Data instance and one BusinesServiceModel instance, making it a singleton without needing code. The Data instance is kept for the lifetime of the BusinessServiceModel instance. Also to programatically make it a singleton means having extra public methods that aren't on the DBMain interface which isnt a good idea.
2. This is one I struggled on. I originally got it to read the structure and then use those indexes to find what column was what. This required either (a) my Data class to know about the structure of the database rows or (b) my Data class to have extra methods on it for extracting the schema so my BusinessServiceModel could learn the structure. Both these options seemed wrong, especially (a), as it is a database impl, and should never care about what data it is storing. (b) seemed wrong too, as the interface they had provided in DBMain does not allow for this. So the solution is to document this in my choices file, and to hard code my BusinessServiceModel to know that when it gets a String record, that index x gives me column x from a row.
Ok, thats about it. Hope it helped - if you have other ideas let me know, I am always keen to alter my design if it makes it better.