Forums Register Login

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

+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
 

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?

+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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".
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
Hi Roel,

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

BR,

Mika
+Pie Number of slices to send: Send
I used database level locking...
+Pie Number of slices to send: Send
 

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
Do not threaten THIS beaver! Not even with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1550 times.
Similar Threads
B&S locking solution - consumes no CPU cycles
Locking dumb question
Hand-over-hand locking not needed in SCJD book example ?
Removing entry from HashMap when storing ReentrantLocks safely
Will this locking mechanism be allowed?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 03:28:19.