Do you think this is ok solution:
1) The user selects the row
2) The user fills the owner field with the owner number
3) The user presses the book button
4) The book method is:
-Locks the record
-Reads the record
-If the record is already booked throws the AlreadyBooked exception
-Updates the record
-Unlocks the record
3) How about the general user interface? How good it has to be? I don't have the tooltips, menu's, centering of the windows etc.
Johnny Barbosa wrote:Look, do you agree with me, that, once time the record was booked, your application can to know if a record selected can be booked or not?
Well, that could be done by calling the read() method, passing the number of the selected record. If this record is already booked (or the customer ID field is not empty), then it makes sense to throw an exception to the upper layer. The approach addressed by Mika looks pretty much like the one I implemented in my bookRoom() method of the business layer.
Johnny Barbosa wrote:Ok! In my Sun Interface not have a method like "reserve", but only "update".
Do you think so that 2 phase locking is really needed? I think my solution would be simpler if
I would have only one lock. I know that in one lock situation the thread can wake up if the wrong
record is released and it has to wait again. Then some cpu cycles are consumed, but is that violating the requirement?
How about the general user interface? How good it has to be? I don't have the tooltips, menu's, centering of the windows etc.
Mika Tapanainen wrote:If I understood you correctly, you had the synchronization only on the database level, not on the record level?