|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// Creates a new record in the database (possibly reusing a
// deleted entry). Inserts the given data, and returns the record
// number of the new record.
public int create(String [] data) throws DuplicateKeyException;
Regards, George
SCJP, SCJD, SCWCD, SCBCD
He can leave other fields like smoking, rate, date and others if not known. 
I am just curious to know. Can you answer a couple of questions?
Originally posted by Satish Avadhanam:
1. Which lock mechanism did you use: Record Locking(static lockedRecoords)/RAF synchronization?(Mine is Record Locking)
My locking mechanism was extremely simplistic. I made no claims that the application as designed is highly concurrent (it isn't, but that's not a requirement specified in the assignment instructions), only that the solution is thread-safe and easily understandable. I'll paraphrase the relevant sections of my design document at the end of this post.
2. Did you expose the locking to client(as Andrew did) or not(as Phil's choice)? Personally I do not want(as a matter of fact, did not) to expose any locking to the client. All I want to provide to the client is the two business requirements, search and book. That's it. Any comments on this?
I did expose locking to the client, so my application follows the traditional two-tier client server model. The main reason I did this was a statement in the assignment instructions:
The main architecture of the application must be a traditional client-server system. There are three key parts: the server-side data management system, the client-side GUI, and the network connection between the two.
I think either two-tier or three-tier implementations can be successful, and I understand the three-tier model has much to recommend it. Moreover, I believe the three-tier implementation is probably a better solution than the two-tier. However, in my opinion what is required for the exam is a reasonable solution that is well implemented. In other words, I don't think candidates who choose a three-tier approach have an advantage over candidates who choose a two-tier approach even though the three-tier approach may be technically superior. Absolutely nothing in the assignment instructions suggests that the approach should be three-tier rather than two-tier. I'm suggesting that you worry less about picking the "best" solution and pick a "good" solution and spend your time making sure your "good" solution is as well implemented as you're capable of making it. A well implemented "good" solution trumps an imperfectly implemented "best" solution in my estimation (this is probably true in real life as well, but I think it's definitely true for the exam). So pick a reasonable solution that appeals to your sensibility and then try to avoid second-guessing your decision and concentrate instead on creating the perfect implementation of your solution. It is probably the case that a simple reasonable ("good") solution is easier to implement perfectly than a complex sophisticated ("best") solution.
The last one is, its not a question, but can you comment on it? What I want to do is as I'm not providing client side locking, when two clients tries to book the same room, I will allow the first thread which reaches to book and for the second one, I want to throw a message that the record was just booked. Its OK right. What do you say?
It seems to me that there are three cases:
1) the record is unbooked, a client tries to book the record, the record is booked for that client,
2) the record is already booked, a client tries to book the record, booking is prohibited for an already booked record, so an exception is thrown and the client is notified of the violation.
3) the record is already booked, a client tries to book the record, the record is booked for that client (overwriting the booking of the previous owner of the record).
I think the assignment instructions require that you implement case 1. I think the assignment instructions permit you to implement either 2 or 3 (as they are mutually exclusive). How to choose whether to implement 2 or 3? Which of 2 or 3 is easier to implement?
By the way, I chose to implement case 3. I believe case 3 is only acceptable if the client knows that the record is already booked. That is, if you allow a client to book a record that has already been booked, it is imperative that you let the user know that the record was already booked. So, for example, it is unacceptable to let a client book a stale record, that is a record that appears (in the JTable) to be unbooked but in reality has already been booked by another client. It is perfectly acceptable to allow a client to book a record that is already booked as long as the client knows the record is already booked. This stale record problem is the reason that I required a lock, read, update, unlock sequence in my book operation.
Locking Approach
I implement locking in the Data class itself by using a Vector of record
numbers to indicate which records are locked...
All the public methods (except for lock, unlock, and isLocked) of the Data class that access the database file are synchronized so that attempts at concurrent access of the database file are sequentialized. All code accessing the Vector of locked records is synchronized on the Vector to sequentialize concurrent access attempts of clients calling the lock, unlock, or isLocked methods.
To ensure thread safe behavior of the database operations it is necessary to follow a lock/database_operation/unlock protocol, where database_operation is any of the database operations such as read and update...
...Adhering to the lock/database_operation/unlock protocol results in a guarantee that only the client who obtains the lock on a record, may unlock that record. This locking scheme provides consistent concurrent access to the data in a multiple client environment.
While locking is only necessary when the database is in remote mode and can be accessed in a multiple client environment because of RMI, it is implemented so that it will also work correctly when the database is in local mode and is accessed by only one user.
Database operations performed in a locked context are thread safe meaning
that dirty reads and dirty writes are not possible. Some database
operations may be performed outside the locked context to achieve better
performance due to less waiting. For example,...
In network mode if the client application were to die for whatever reason
after the client had obtained a lock and before it was able to call unlock,
then that record would remain locked until the server was shutdown and
restarted. The code does not currently handle this sort of client death
situation. This should be handled in the final production system, but I
decided not to implement it now since I believe it is out of the scope of
the assignment...
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Originally posted by George Marinkovich:
Hi Satish,
I think either two-tier or three-tier implementations can be successful, and I understand the three-tier model has much to recommend it. Moreover, I believe the three-tier implementation is probably a better solution than the two-tier. However, in my opinion what is required for the exam is a reasonable solution that is well implemented. In other words, I don't think candidates who choose a three-tier approach have an advantage over candidates who choose a two-tier approach even though the three-tier approach may be technically superior. Absolutely nothing in the assignment instructions suggests that the approach should be three-tier rather than two-tier. I'm suggesting that you worry less about picking the "best" solution and pick a "good" solution and spend your time making sure your "good" solution is as well implemented as you're capable of making it. A well implemented "good" solution trumps an imperfectly implemented "best" solution in my estimation (this is probably true in real life as well, but I think it's definitely true for the exam). So pick a reasonable solution that appeals to your sensibility and then try to avoid second-guessing your decision and concentrate instead on creating the perfect implementation of your solution. It is probably the case that a simple reasonable ("good") solution is easier to implement perfectly than a complex sophisticated ("best") solution.
Thanks George for a very good advice. Actually what is happening is I read the different posts here and different designs, I'm coming up with new ideas. So the design is constantly changing. The reason why I am not able to stick to a particular design is this is very new to me. I don't have any expereince in any of the issues for SCJD. Its like everything is NEW. If you have observed, I generally ask pretty much asking very dumb quetions toobut y'll guys are very very helpful. So as I read posts, you know...I thought am getting better and better and so the design is also getting OK. But as you said, there are quite a huge variety of designs in the ranch and its making me I will try to stick to one. Thanks.
It seems to me that there are three cases:
1) the record is unbooked, a client tries to book the record, the record is booked for that client,
2) the record is already booked, a client tries to book the record, booking is prohibited for an already booked record, so an exception is thrown and the client is notified of the violation.
3) the record is already booked, a client tries to book the record, the record is booked for that client (overwriting the booking of the previous owner of the record).
By the way, I chose to implement case 3.
George, I think I'll stick to 2.
|