NX: UrlyBird reserve requirement question

[Chee-Chan Keng]

Hi,
Question 1:
===========
My GUI requirement states that:
"It must allow user to book a selected record, updating the database file accordingly"
But it did not mention "unreserve" the record, does that mean we just let the user book but cannot un-book the hotel?
Question 2:
===========
Also, in the interface, I have the following methods, are my assumptions correct and meet the requirements:
public String[] read(...) - no GUI implementation
public void update(...) - associate GUI with "book" button, can this be translated to updating the "owner" field with customer name? which implies that the user can only modify the "owner" field in the record? or all fields in the record?
public void delete(...) - no GUI implementation
public int[] find(...) - associate GUI with "search" button, assume hotel with empty "owner" is available.
public int create(...) - no GUI implementation
public long lock(...) - no GUI implementation, but used when other methods are called.
public lon unlock(...) - no GUI implementation, but used when other methods are called.
Question 3:
===========
If lock() is called and JVM crashes, we assume all records are lock free when we restart the application, right? I see other people are using complicated methods to generate the cookie, if I just use an int and increment the value from my server, my cookie should be unique enough, why do they need to use Math.random() or other techniques to generate the number?

thanks a lot!!!
[ March 08, 2004: Message edited by: Chee-Chan Keng ]

[Satish Avadhanam]

Hi Keng

Originally posted by Chee-Chan Keng:
Hi,
Question 1:
===========
My GUI requirement states that:
"It must allow user to book a selected record, updating the database file accordingly"
But it did not mention "unreserve" the record, does that mean we just let the user book but cannot un-book the hotel?

If you want to allow the user to unbook, its OK. Some allows to unbook, some don't. Whatever you assume you need to document though and provide the implementation accordingly.

Question 2:
===========
Also, in the interface, I have the following methods, are my assumptions correct and meet the requirements:
public String[] read(...) - no GUI implementation

Yes.

public void update(...) - associate GUI with "book" button, can this be translated to updating the "owner" field with customer name?

Yes, you can re-use the given update method to book the record instead of providing another one.

which implies that the user can only modify the "owner" field in the record? or all fields in the record?

We have to implement update method such that it MUST be able to update all the records. Note that this functionality is not used at GUI though. We can use the same update method to book as said before.

public void delete(...) - no GUI implementation

Yes.

public int[] find(...) - associate GUI with "search" button, assume hotel with empty "owner" is available.

This method can be used as part of search functionality. But if you take another look at the find method and the GUI search requirements, we need to have another find method that does exact search. This method, as per my instructions does "startsWith" search. But GUI search needs exact search.

public int create(...) - no GUI implementation

Yes.

public long lock(...) - no GUI implementation, but used when other methods are called.

Yes and No. It depends on your locking mechanism. Some people provide client side locking capabilites. Then you must provide this in GUI.

public lon unlock(...) - no GUI implementation, but used when other methods are called.

Same as above.

Question 3:
===========
If lock() is called and JVM crashes, we assume all records are lock free when we restart the application, right?

I would say yes. Locks are not persisted, so they live as long as JVM is up. Once it crashes application losts knowledge of all non-persistent objects including locks in the application.

I see other people are using complicated methods to generate the cookie, if I just use an int and increment the value from my server, my cookie should be unique enough, why do they need to use Math.random() or other techniques to generate the number?

You can use a number for cookie as long as you are sure it is unique.

thanks a lot!!!
[ March 08, 2004: Message edited by: Chee-Chan Keng ]

Good Luck

[Gaz Smith]

I've also been pondering the unique cookie issue recently. I've read various threads that discuss the use of
1. The system time. This is flawed in some instances since sequential calls to System.currentTimeMillis() can return the same value.
2. A random number generator. Can also return the same number although clearly the chance is probably suitably remote for these requirements.
3. An incremental integer. As suggested above. The two obvious drawbacks seem to be, that it offers no security since the cookie can easily be guessed (although is security in anyway a requirement?) and two the counter will eventually wrap and cause you problems.
I prefer the idea of 3 since it wouldn;t be hard to justify the lack of security in this spec. I was thinking however of using a stack instead of a simple incremental counter. This way cookies are returned once they're finished with and it's unlikely you'll run out of cookies this way (c.f. counter wrap).
Any thoughts?
p.s. This forum has been a god send. I've been lurking for a while but simply haven't needed to post since I've been able to find sufficient detail from past posts! Just like to take this opportunity to congratulate everyone involved.

[Satish Avadhanam]

Hi Smith,

Originally posted by Gaz Smith:
3. An incremental integer. As suggested above. The two obvious drawbacks seem to be, that it offers no security since the cookie can easily be guessed (although is security in anyway a requirement?) and two the counter will eventually wrap and cause you problems.
I prefer the idea of 3 since it wouldn;t be hard to justify the lack of security in this spec. I was thinking however of using a stack instead of a simple incremental counter. This way cookies are returned once they're finished with and it's unlikely you'll run out of cookies this way (c.f. counter wrap).
Any thoughts?

Using stack to return the unused cookies is OK, I think and as you said will not run out of cookies. If we are using "long" as cookie object, then for assignment scope its unlikely that we run out of cookies and simply ignore this issue and document it accordingly. Performance, Sercurity and some other issues can be ignored for the assignment scope, but as I said we need to state our assumptions clearly to grader.
Good Luck

[George Marinkovich]

Hi Gaz,
Welcome to posting in this forum.

Originally posted by Gaz Smith:
I've been lurking for a while but simply haven't needed to post since I've been able to find sufficient detail from past posts!

Absolutely, that was my experience as well.
My project didn't require lock cookies, but if it had then I would have used option 3, a one-up-counter. If you use long as the type of your counter I suspect the CSR's hands will have fallen off by the time wrapping occurs. A client would have to hold lock for so long that wrapping occured while he retained the lock. Then the worst case scenario would be that there would be duplicate lock cookies.

[Gaz Smith]

thanks george.
i agree with you.
now that my posting 'viginity' is lost i'm sure you'll be hearing from me again in the not too distant future ;-)