It's not a secret anymore!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes 1) no cpu cycles 2) book a selected record 3) the general user interface level Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "1) no cpu cycles 2) book a selected record 3) the general user interface level" Watch "1) no cpu cycles 2) book a selected record 3) the general user interface level" New topic
Author

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

Mika Tapanainen
Ranch Hand

Joined: Jun 11, 2009
Posts: 95
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


SCJP, SCJD, SCEA
http://fi.linkedin.com/in/mikatapanainen
Johnny Barbosa
Greenhorn

Joined: Sep 29, 2009
Posts: 26
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?


Cheers,
Johnny Barbosa
SCJA, SCJP, SCWCD, SCJD(Story | Relato), SCBCD (coming soon)
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2266
    
    3

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.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Johnny Barbosa
Greenhorn

Joined: Sep 29, 2009
Posts: 26
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
Bartender

Joined: Dec 28, 2007
Posts: 2266
    
    3

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
Ranch Hand

Joined: Jun 11, 2009
Posts: 95
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
Bartender

Joined: Jul 19, 2004
Posts: 5406
    
  13

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


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Mika Tapanainen
Ranch Hand

Joined: Jun 11, 2009
Posts: 95
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
Bartender

Joined: Dec 28, 2007
Posts: 2266
    
    3

I used database level locking...
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5406
    
  13

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
 
 
subject: 1) no cpu cycles 2) book a selected record 3) the general user interface level