Relationship between locking and GUI

I am working with the DBAccess interface that requires locking and unlocking to a record before and after update record. There are many ways how to implement this in conjunction with the GUI and data concurrency issues.

I have the following options in mind:

========
Option 1
========
1) Both user A and B select the same record in the JTable and hit the booking button.
2) A modal booking dialog is shown for each client that provides a JTextField to enter the 8 digit booking code.
3) Both users type their booking codes which are differet. e.g. User A types 11111111 and user B types 22222222.
4) Both users hit the OK button.
5) On the server side the lock, update and unlock methods are called one after the other. Assume user A was 1ms faster/earlier than user B, so his value 11111111 is written in the database file, then after 1ms user B value 22222222 overwrites user A value in the database.
6) The booking code for the selected record is updated in the UI to value 11111111 for user A and to value 22222222 for user B.

========
Option 2
========
1) Both user A and B select the same record in the JTable and hit the booking button.
2) Before showing the booking dialog, each user tries to lock the selected record first, assume user A locks the record before user B.
3) User A sees the booking dialog, while user B's GUI is blocked untill user A unlocks the selected record.
4) User A types the booking code and hits OK, his value is written to the database and the record is unlocked.
5) User B gets the lock on the record and sees the booking dialog, the booking dialog shows the value 11111111, user B can change it or cancel the dialog.

========
Option 3
========
1) Both user A and B select the same record in the JTable and hit the booking button.
2) Before showing the booking dialog each user gets the records timestamp.
3) Both users type their different booking codes and hit OK at the same time.
4) The timestamp requested when the dialog was opened is sent to the update method, if the time stamp inside the updated method is the same as the database timestamp then the update method continues as usual, else if the time stamp is different then the update method throws an excption.
5) In the UI user A saves successfully while user B gets the error message: the record you tried to book was changed in the meantime, please refresh your UI and try again later.

So, what solution is OK for the exam? will these solutions be graded equally?
Can you share with me/us what solutions you used that made you pass the exam.

When 2 clients both want to book the same room (record), one client will succeed and thus will have booked the room. The other client will get an exception (e.g. "room already booked") and will not be able to book this room anymore. Because you don't want double bookings for the same room. It's not funny at all if you have booked a room with your wife for a romantic weekend and when you arrive at the hotel you notice another couple have booked the same room too

In your overview of the possible options that's option 4 ;) (but is a combination to option 2 and 3, but easier than 3)

for your information: about option 1, I'm very curious how you are gonna save 2 different customer ids in 1 field for different clients

5) On the server side the lock, update and unlock methods are called one after the other. Assume user A was 1ms faster/earlier than user B, so his value 11111111 is written in the database file, then after 1ms user B value 22222222 overwrites user A value in the database.

Well, that can't happen. The purpose of the locking mechanism to be implemented by you is to avoid these exact situations. The thing is, before updating a record, you have to lock it. After acquiring its lock, you read it to verify if it is still available to be booked (if the client ID field is still empty). If so, then you proceed wih the booking normally and unlock it. If it is not available, then you can throw a business exception (i.e. RoomAlreadyBookedException) and unlock the record. The orchestration of these operations is performed in a business method of your business layer (i.e. bookRoom() method).

So when first client locks the record, he'll see that the record is available. Meanwhile, the Thread of the second client will probably be waiting, because he also called the lock() method, but your lock() method noticed that the same record the second client wanted to update was already locked by the first client, so it put the Thread of the second client in a waiting state. The first client updates the record and unlocks it. Then, the Thread of the second client wakes up and acquires the lock of the record. He'll read it and see that it was already book. That's when the business exception is thrown.

Option 2:

2) Before showing the booking dialog, each user tries to lock the selected record first, assume user A locks the record before user B.

Well champ, that can be a problem... what if the user A's machine crashes, leaving the record locked forever? Then you'll have to come up with a mechanism to avoid such situations, and then you would be introducing unnecessary complexity. In your bookRoom() method, all you have to do is call the lock()/update()/unlock() sequence and you will do fine!

Option 3:

4) The timestamp requested when the dialog was opened is sent to the update method, if the time stamp inside the updated method is the same as the database timestamp then the update method continues as usual, else if the time stamp is different then the update method throws an excption.

There's no need to introduce such complexity... also, remember, that you can't change the interface provided by Sun. Just remember to keep things simple and you'll do well!

I don't have a hotel room scenario rather a contractor book/unbook one. I don't save more than one customer ID for one contractor, my idea was to allow the user to change the booking of a contractor from customer 1 to customer 2. In a hotel room scenario this is not possible of course, but in a contractor/customer scenario this could be legitimate because when contractor X finishes his service for customer 1 then he can directly be assigned to customer 2.

But you are right, since the specification is not clear enough about the business rules, I can make my own assumptions and document them, this gives me the opportunity to make the solution simple.

I will follow your advise and throw an exception if an attempt is made to book and already booked contractor, I can force the end users to book only vacant contractors.

I don't have a hotel room scenario rather a contractor book/unbook one. I don't save more than one customer ID for one contractor, my idea was to allow the user to change the booking of a contractor from customer 1 to customer 2. In a hotel room scenario this is not possible of course, but in a contractor/customer scenario this could be legitimate because when contractor X finishes his service for customer 1 then he can directly be assigned to customer 2.

Agreed. However, the unbook feature is not required, so you don't have to implement it. In fact, I'd say that 99% of the people who pass this certification don't implement it.

If you have more questions, please let us know!

I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com