1) no cpu cycles 2) book a selected record 3) the general user interface level

[Mika Tapanainen]

Hello and thanks for this excellent discussion group!!

I have different B&S questions:

1) My interface has DB.lock method and the requirement is "If the specified record is already locked by a different
client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked."

I implemented the 2 phase locking, I have the MasterLock and the RecordLocks. The MasterLock is for the HashMap locking. The HashMap contains
record numbers and the RecordLocks. The RecordLocks are for the locking of the records.
Now no CPU cycles are consumed when the thread waits for the lock of the some record.

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?

2) I have the user interface requirement "It must allow the user to book a selected record, updating the database file accordingly".

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.

Thanks,

Mika

[Johnny Barbosa]

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.

Hi Mika,

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? So, not is necessary throws a "AlreadyBooked exception", because you can to prevent the user to book a record already booked, understand me? If the user select a record booked, at most that he can to do is to release that record, right?

[Roberto Perillo]

Howdy, y'all.

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.

Mika, just make sure to arrange your algorithm in a try/finally structure, so that the unlock() method is always called.

[Johnny Barbosa]

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.

Ok! In my Sun Interface not have a method like "reserve", but only "update".

[Roberto Perillo]

Johnny Barbosa wrote:Ok! In my Sun Interface not have a method like "reserve", but only "update".

Right... well, "reserve" looks more like a service that has done by the application, so it would be nice to define a layer that offers these services (such as booking or searching). There, we could implement all the required business logic to correctly perform these services.

[Mika Tapanainen]

Hello,

my solution of the book method is like Roberto describes in his first reply. I'm also using try and finally.

How about my other questions? Do you have opinions about them?

Thanks,

Mika

[Roel De Nijs]

Hi Mika,

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?

I used synchronized-keyword and wait/notifyAll to make my Data class thread-safe. And I passed, so I think this approach is certainly not violating the requirements.

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.

It depends on how good you want to score of course. My Gui had everything: tooltips, mnemonics, menubar (with just 1 item), centering, dynamic buttons disabling/enabling, not allowing alphanumeric characters in numeric field (for example port number),...

Kind regards,
Roel

[Mika Tapanainen]

Hi Roel,

If I understood you correctly, you had the synchronization only on the database level, not on the record level?

BR,

Mika

[Roberto Perillo]

I used database level locking...

[Roel De Nijs]

Mika Tapanainen wrote:If I understood you correctly, you had the synchronization only on the database level, not on the record level?

Indeed, my Data class was a singleton and all my methods were synchronized. The most easy approach as far as I know, maybe not the most performant and fast (but that wasn't a requirement, and simple, easy to understand code was).

Kind regards,
Roel