Steve Wang

oli: I got my grade back and got 375. I lost 13 in documentation and 12 in GUI. I thought I did a good GUI and obviously not good enough to SUN's grader. It seems you did a good job on these two sections. Can you post a snapshot of what your GUI look like so that I may get some sense? Thanks.
What your next exam plan? SCEA? I am thinking is it is appropriate to proceed to SCEA after SCJD.

- Steve

i do not use any cookies at all. I simply used a HashSet in Data class to store those locked record numbers. That is all.
- Steve

Just my 2 cents: my personal experience in passing the exam is that I read a lot of posts/comments/suggestions on this forum. I did not read any books although I bought one copy. This forum is very helpful and specific sometimes in getting it passed.

This is really nice and helpful forum. Thanks should go to those experienced java guru like Andrew, Philippe, and Peter den Haan etc. Their posts are very helpful in passing the exam.

Sun also did great job in grading -- it just takes less than 2 weeks to get grade back.

General Con: 100 100 Documentation: 70 57 OOD: 30 30 GUI: 40 28 Locking: 80 80 Data Store: 40 40 Network Server: 40 40 Total: 400 375

Unfortunately I lost most points in documentation, and some in GUI. I wrote 2 pages long, but obviously it is not long enough...

Some notes to those who are working on exam: I used very, very simple locking mechanism. Think simple.

- Steve
:roll: :roll: :roll: :roll: :roll:

I am now ready to upload assignment and got the following message. Anyone knows what went wrong? Thanks.

"You do not have the rights to upload that assignment. Press the "Back" button on your browser and try another assignment. If you feel that you should have the ability to upload, please email us at [email protected] for assistance"

Thank, Andrew.
I understand what you described.
I used a different strategy. I implemented a MVC pattern on client side (GUI). My BrokerModel contains a reference of IndependentAdapterInterface which polymorphically invokes on bookRoom method etc. This reference does not care which implementation is between RemoteAdapterImpl and LocalAdapterImpl. My RemoteAdapterImpl was implemented using a Decorator pattern.

I do not disagree with you. Your suggestion is one way out. Thanks for your precious input.

- Steve

Hi, Andrew -- i am a little confused with what you described above. Do you mean that I need only one class for both remote networked and local non-network modes? Whatever OO patterns you use, you have got to somehere to tell the difference between remote and local mode, more or less. Through inteface reference, we may polymorphically invoke appropriate methods.

If you think, that i still need two classes "RemoteDataAdapterImpl" and "LocalDataAdapterImpl" to implement appropriate interfaces, the only way to elimiate the duplicated code for bookRoom method is to use lock/update/unlock in the class "LocalDataAdapterImpl", and use delegation to this class inside "RemoteDataAdapterImpl".

Please make it clearer!

From Hanna Habashy's comments,
I think that client A is allowed (and shoud be) to read any records from DB while client B has locked a record and got ready to update (write to) DB. Of course, while client B is physically updating (writing to) DB, client A needs to wait after client B finishes update(..) due to sync'ed file pointer access concern.

I implemented the same way as what Guvenc Gulce described above. When client A fills in his client ID (from your snapshot view in GUI) and book a room (in my URLybird assignment), he may not necessarily get booked since the room could get booked by someone else while client A is viewing the search result.

Do those experienced ranchers here like Andrew, Peter den Haan, or Phillippe have any smarter thoughts?

- Steve W.

In my application, I have one interface like "IndependentDataInterface" from client side to polymorphycally call DataAdapter's methods. I used a Decorater pattern here to delegate calls inside the class "RemoteDataAdapterImpl" to the class "LocalDataAdapterImpl" (a kind of technique used in Java I/O hierrachy).
So bookRoom method
1). for class "LocalDataAdapterImpl' is simply like (no lock/unlock is invloved):
Data.update(...)
2). For "RemoteDataAdapterImpl" has to be different by adding lock/unlock functionalities like:
Data.lock(recNo)
Data.update(...) // or could delegate to "LocalDataAdapterImpl" update(..) method.
Data.unlock(recNo)

I agree with Andew, that from OO design viewpoint, lock/unlock must be used in "LocalDataAdapterImpl" for non-networked mode. On the other hand, from the assignment specification, lock/unlock should NOT be used for lock/unlock since only ONE client is assumed to use the system, as far as lock/unlock overhead is concerned for non-netowked mode.

Any brighter ideas here, please advise, ranchers! Thanks.

Why do you want to lock all records when performing search? The only scenario that you need lock/unlock is that you want to update (i.e. write to) database.

Just my 2 cents

Thanks, Mark, for comments.

So which way do you think better for the purpose of exam?

i implemented no-lock's update for non-networked mode. It seems there is a little more code compared with what you mentioned above.

I have a question and wish to get some help from many java guru here.
I felt that there is no need to use Data.lock(recNo) before Data.update(recNo,..), and Data.unlock(recNo) after Data.update(recNo, ..). I am not quite sure although i believe so. Can anyone enlighten me please?

BTW - i did use lock/unlock for update in networked mode.

Thanks in advance.

I was wondering why you want to use lock/unlock for inside Data's read().
My bookRoom method is a method a DataAdapter which simply wraps up Data and provides business-tier operations. In order to access to Data, client must call DataAdaper's bookRoom method, which in turn calls Data's lock, update, and unlock methods. My question is that a record cannot be double-booked.

You are right and we need to make sure no deadlock occurs. What about race condition? Have you though of the case that a client dies/crashes while this client holds lock without unlocking? There may be other rare scenarios too.

Thanks for suggestion. I do have a multi-tier validation check, including client-side checking and server-side checking.
If I implement what you mentioned above at server side, it does ensure that an "already-updated" record will not get overwriten (i.e. a record won't get booked twice). If this is the case, how do you handle cancellation/re-book scenario like: Client A booked a room as indicated a valid ID in DB last week, and now want to cancel the booking. We should make this record bookable again by making owner field empty.

I have read a few posts here. There are a lot of good discussions (like Peter Den Haan, Philippe Maquet etc ). Most of them handle booking in the way as you mentioned above.

In addition client-side checking, I am going to do server side checking as well. Before tryin to update a record by entering owner ID, I will check to see if this record is bookable (i.e. an empty owner field ?) No overwrite is allowed in DB. It is obvious that cancellation of a booked record is not allowed. Therefore my bookRoom method at business tier like this:
lock
if (isBookable() ) // inside isBookable(), call db.read(recNo) and check owner field
update(recNo)
unlock

Please make comments if I am working to the right direction.

I am almost ready to upload my assignment, but felt that there may be an issue.

I have a business-tier method of bookRoom which does the following logics:
db.lock
db.update
db.unlock

Suppose I have two threads A and B trying to update DB at the same time. While thread A invokes bookRoom for client A, thread B calls bookRoom as well. So thread B goes to sleep, relinguish CPU, and such. After thread A finishes update by writing an owner ID (i.e. 111) to DB and unlocking, thread B gets lock and should be able to update DB by writing another owner ID (i.e. 222) to DB.

Now if client A tries to search all records, A will be surprised to find that he/she did not get room booked. Should I allow such scenario to happen.

I implemented a way of not allowing a "booked" record to be updated again in my GUI. When a client selects a record in JTable which has a valid owner ID, I simply disable the owner field. Only empty owner field in JTable is allowed to enable owner text field for booking. I implemented validation check for owner text field to check if user's input is digit and only 8 digits is maximally allowed. But this still may have drawback. What if a client changes his mind to cancel his booking/reservation?

However, if I allow repeated updating no matter if a record has booked as indicated by a valid owner ID, this seems undesirable also.

Please enlighten me