Win a copy of 97 Things Every Java Programmer Should Know this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger

UrlyBird DBMain puzzles

Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have the UrlyBird 1.3.2 assignment. The DbMain interface that I have to implement is quite confusing and I would appreciate some help/opinions on it.

1) There is a create method listed - but there is no way that the client I am developing should ever need (or be able) to create a room availability. Should I provide an implementation for the interface method, or would it be sufficient to provide a blank method and then document it as such?
2) The interface refers to "record numbers". Is this just the number assigned to each record, in order of reading from the file? Will those record numbers ever change?
3) When someone "books" a room, should it be deleted from the file, or just a customer ID entered for it? And if the latter, should other clients ever even see that record at all (in other words, should clients only ever see available rooms)?
4) There are lock and unlock methods, but I am puzzled by them. What happens if a lock is obtained by a client, who then logs off abruptly or otherwise just stalls forever and ever. Should the lock be released after some time period?

Sorry for all the questions, but this aspect of the specification has been particularly difficult for me to understand. Thanks!
Ranch Hand
Posts: 387
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Bernard,

I did UrlyBird last year (can't remember which version)

1. yes, you have to provide an implementation. GUI and serverside are two different things. Sun will probably run a script to test your "create" method.

2. Yes, it's just the number assigned but don't know if it changes. I assumed it didn't.

3. If your specs don't say it should be deleted, then don't make it. Just make what they ask. Same goes for hiding booked rooms: does it say so in your specs? If not: don'make it.

4. If you lock client-side that's possible. I choose to lock server-side only. Server does not go on holiday without unlocking...

Bernard Russell
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Herman - thanks for the reply and for taking the time to answer my questions.

I am developing a middle-tier server to the client that looks a little more logical. It allows clients to book a room, or search for vacancies, but does not allow access to locking or deleting them. That solves many of the problems with the odd interface.

I am slowly getting to grips with the exercise, but it's tricky. Thanks again for your comments!
Those are the largest trousers in the world! Especially when next to this ad:
Devious Experiments for a Truly Passive Greenhouse!
    Bookmark Topic Watch Topic
  • New Topic