Originally posted by Mike Tilling:
does your assignment have this spec
"They take bookings only within 48 hours of the start of room occupancy" ?
Is the date field described as follows
"Date available : The single night to which this record relates, format is yyyy/mm/dd" ?
I see that you did not take date in consideration, if the owner is empty than you book the record, what if the date is not within the next 48 hours?
-when you book the record, you only provide the custoner ID, what about the new value for the date field, do you keep the same date for ever?
Originally posted by Mike Tilling:
1- What do you provide as parameters when booking the selected record?
I will implement the booking method as follows (Thanks to Edwin Advice):
-On a create operation, I will provide all values including the customer
-The room can be booked if the owner is not empty regardless of what the date (available date) is. If the date is 10/10/2005 (one year ago) and the owner is not empty then the room can not be booked, what the user should do is to unbook the room to reset the owner into blanks or reaffect it to an other customer, the unbook reset the owner regardless of the date value.
in other words :
The booking request will be accepted if (date is today and owner is empty)
Or (date is tomorrow and owner is empty) or (date is after tomorrow and owner is empty).
3-If date is after today +48 hours and the owner is empty, will the room be ready for booking?
Originally posted by Peter Jakobsen:
But always document your design choices, this is a major design choice, and the pros and cons should be discussed in your documentation.
Originally posted by Roy Mallard:
OK I've had a quick look at it...kind of hard to understand since you don't describe your locking strategy.
That synchronized (lockObject) line looks a bit suspicious. Are you sure there will only ever be one lockObject object for each record? What happens to the lockObjects when a record is deleted/created?
Originally posted by Peter Jakobsen :
You are using a HashMap to store locks. HashMap is not thread safe, so you need to exclusive access, when inserting locks in your lock handler. From what I can see, it looks like to threads can lock different records, and thereby modify the HashMap simultanously.
Originally posted by Tony Bouer:
I can't see how this code is going to solve the issue I raised. If you are on the waiting state and receive the "go ahead" (the recNo is not locked anymore) so you should verify again if the record still valid or not. It could be deleted or updated with an owner making it non availble for update or delete.
Regards,
Tony
Originally posted by Daniel Bryant:
1. Client A Locks Record 1.
2. Client B attempts to lock Record 1 - waiting
3. Client C attempts to lock Record 1 - waiting
4. Client A deletes Record 1
5. Client A unlocks Record 1 - notifyAll()
Now if you don't check if the record is deleted in your locking code how do client B and C deal with this? do they lock a non-existant record (and does this make sense-could this impact another thread creating a new record), or does only one client recieve notification and the other thread waits indefinitely?
Originally posted by Tony Bouer:
I think it's strange to follow the reqs without taking care of this situation. Anybody has any comments on both cases ?
Any help would be fine !
Originally posted by Mark Linese:
Are you checking for the record validity (non-deleted / non-owner) after a wait inside lock method ?
Originally posted by Al Purvis:
Thanks all. Based on the results of this thread I passed today. It was only a couple of minor changes and I got a 371/400. Most missed points were in the GUI.
Hope to see you in the SCEA.
Originally posted by Mihai Radulescu:
I propose you an other method name for your "findWith48hRule....
Originally posted by Mihai Radulescu:
What you understand by business rule ?