Doubts reagarding database operations for Bodgitt and Scarper

[Anayonkar Shivalkar]

Hi,

Currently, I've divided the assignment in 3 parts:
1) Database operations
2) Networking
3) UI

(however, I believe networking and UI combined would take equal/less effort as database operations)

So, currently, my approach is : once I get perfect with DB thing, rest won't be much complicated (correct me if I'm wrong).

However, I'm having below doubts:

1) Assignment only talks about search records and display those records. Only operation which writes to DB file is reserving the record. So, do I really need to write a valid code for create and delete methods (since those are part of given interface)? Can I simply write fake methods (return null etc.) and never make calls to those?

2) Interface also says that create method should create a new entry by reusing a deleted entry. Again, this part is not mentioned in actual instructions, but mentioned in code comments of give interface. So should I write such code, even after knowing that that method will never be called?

3) There are lock and unlock methods which I 'must' implement. However, is it necessary to provide a facility to client to explicitly lock and unlock records? I am thinking about below approach:
Client simply make an update request and provides the data (it will only be one filed to be updated). Server takes the data, internally locks the record (and db file), writes the data and unlocks the file. This will make lot of other things easier like:
a) I don't have to worry about which client locked which record. Server locks the record, and performs the operation. During this time, if another client makes an update request, it will not get the lock.
b) No worry about deadlock, since one client can never lock more than one record.
c) No worry about client crashes. Once the update request comes to server, it doesn't care if client lives or dies.

But, as per instructions, one of the top level features (i.e. 'must' requirements) is : 'A data access system that provides record locking and a flexible search mechanism'
So, I'm little confused here about should I keep explicit 'lock' and 'unlock' buttons on GUI or should I follow above mentioned approach?

If that(explicit locking) is required, then I'll have to maintain a map with locked record and client identifier.

4) In such scenarios (where explicit locking and unlocking is necessary), I'm thinking of not allowing a client to lock more than 1 records - to avoid deadlock. Is this approach valid? (I don't think I'm violating any requirements). If yes, how to ensure that one client only can lock one record? How about adding a Boolean field in client-identifier object and setting it to true once the lock is obtained? (by this approach we can also handle 'another locking request must not eat more CPU cycles, but should return false' requirement)

5) How to handle client crashes? Monkhouse's book provided an approach about using thin clients so that its server who actually locks the record. But my question is, once the lock entry goes into the map, and client crashes, who will remove this entry? (I'm using RMI)

6) What should be primary key? Currently I'm having name and location. I have created another class to take care of primary key (since this object would be key in maps related to lock etc.)

7) What exactly should go to configuration file? As per requirement, all 'configurations' should be done via GUI and must be persistent between subsequent runs.

I know my questions are pretty big, but replies on these would be really helpful for me.

Thanks in advance.

[Roel De Nijs]

1/ you could try to throw UnsupportedOperationException from methods which are not used (like create) and document your decision in choices.txt and maybe you can pass the certification with such an approach, but it's a (huge) risk which might be a really expensive one (if you fail, you'll have to resubmit and take the mandatory course if you resubmit after October 1, 2011).

2/ reusing deleted entries is not a "must" requirement, so you don't have to do that if you don't want to.

3/ Your user does not have to explicit click on a lock/unlock button for updating/booking a record. But before a call to update-method your code needs to make a call to the lock-method. If the record is already locked, the thread must give up CPU. After the update-method is finished, your code should unlock the record (so it can be locked by another thread). This is a must requirement, so not implementing like described in the interface you got, will result in a failure.

4/ In my application a client is also not allowed to lock more than 1 record, so that's certainly a valid approach. I know which client has a lock on which record, so when a client has already locked 1 record and it tries to lock another one, an IllegalStateException will be thrown.

5/ I didn't do anythin special for handling client crashes.

6/ for the B&S assignment I think name and location is a valid choice for primary key

7/ For someone who wants to take care of the Data class first, this is a weird question because it has nothing to do with Data class but with the GUI. And there are many threads discussing what should be saved in the configuration file (so you can easily find the answer yourself using the search engine of this forum)

[Anayonkar Shivalkar]

Thanks a lot Roel.

So if I understand correctly : I'll have to write valid code for create and delete method. However, I'll never have to call it. Right?

[Roel De Nijs]

Anayonkar Shivalkar wrote:I'll have to write valid code for create and delete method. However, I'll never have to call it. Right?

If you want to be on the safe side I think that's certainly the thing you should do. If you like a (expensive) gamble, you could settle for not implementing them and document your decision in choices.txt (e.g. not implementing these methods will result in a faster release of the application, so CSRs can use a decent program to book rooms and be far more productive).