This week's book giveaway is in the Programmer Certification forum.
We're giving away four copies of OCP Oracle Certified Professional Java SE 21 Developer Study Guide: Exam 1Z0-830 and have Jeanne Boyarsky & Scott Selikoff on-line!
See this thread for details.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

why lost so many points on locking

 
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I did pass the exam, but only got 44 out of 80 on locking. I did extensive test on my locking strategy and could not think of anything I missed.

My assignment is B&S. The following is some points in my design. I hope that someone could shed some light on what I might have missed in locking.

In my design, the DBMain() interface is exposed to GUI clients because the requirement expects a traditional client-server architecture.

When server/application starts up, all valid contractors are read from the data file and added into a cache called ContractorMap. It maintains a mapping between a record number and its values. This cache is at server-side, thus any change in cache is available to all clients. Any add/remove/update is first updated into the data file and then the cache.

I created a class ContractorDatafile that implements file I/O with synchronization, too. My data class uses the cache (to look up a record's values) and the ContractorDatafile (to write to file) classes.

=== LOCKING strategy ===

Multiple threads can simultaneously call on Data's public methods. Data class implements record locking by controling access to a list of marked records, a record is said to be marked if a client has exclusive update access to it. The list itself is the synchronized object. The following is record locking strategy:

1. A thread first acquires the lock on this list, then it checks to see if the record number it wants to update is already
on the list. If so, someone else is updating the record. The thread waits for a notification on the list.

2. After a thread finishes update, it acquires the lock on this list and removes the record number off the list.
It notifies all threads waiting on the list.

3. The waiting thread wakes up, acquires the lock, ensures that the record number is still available and is not on the
list, and it then adds the record number onto the list (thus marking the record).

4. The thread now has exclusive update access on the record.

Besides record locking in Data class, file access is also synchronized in ContractorDatafile class so that only one thread can write to the file at any given time. In addition, the cache ContractorMap also has synchronization since the mapping between record number and its value will be updated as records are updated/added/deleted.

Deadlock is prevented since under no circumstance would a thread trying to acquire a lock while holding on another lock.

=== END ===

Please note that after a thread acquires the lock, it again checks to make sure the record is still available, something you friends pointed out eariler.

In addition, I specified the following GUI clients' responsibility on locking:

1. Updating records:
We have required client program to correctly uses lock() and unlock() before and after calling update(), respectively. For example, the client must not call update() or unlock() without first successfully lock the record. This is guaranteed because we are writing the client code and there is no one else using the DBMain interface.

With this assumption, we do not worry about a client trying to unlock a record that is locked by another client, because all clients must use lock() and unlock() correctly.

2. Deleting records:
We have required that the client calls lock() before invoking delete(). However, since the record will have been deleted, there is no need to call unlock() after delete() returns.

3. Exception handling during update:
If client is catching an exception from server when calling update(), it must unlock the record. Otherwise, the lock is never released. The best way to do this is for client to wrap any call to update() with a try/catch/finally block and then call unlock() in the finally block.

We are not concerned about client crashing while holding the lock since the requirement does not say anything needs to be done on this. In a real world situation, we would have grouped lock/update/unlock into one method that is executed on server, which method is then exposed to client through a facade interface, this guarantees that lock/update/unlcok are executed in
one single remote call and there will be no need to worry about leaked locks.

=== END ===

What could I miss?

Thanks.
Yan
 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would also be very interested to know that actually, as my locking approach is very similar, and I am up for submit in a couple of days.

 
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Yan Zhou:
1. Updating records:
We have required client program to correctly uses lock() and unlock() before and after calling update(), respectively. For example, the client must not call update() or unlock() without first successfully lock the record. This is guaranteed because we are writing the client code and there is no one else using the DBMain interface.

With this assumption, we do not worry about a client trying to unlock a record that is locked by another client, because all clients must use lock() and unlock() correctly.



I don't know if this could be the reason for deduction, but I will not dare to make the assumption as stated above. I will be assuming that another ignorant or even malovent developer might create a client that does not play by the rules with regard to locking/unlocking. I will therefore design my server such that even an ill-designed client cannot disturb the database's integrity.

So my server will only allow updating, deleting and unlocking of records to a client that has acquired the lock on the record.

Frans.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Yan,

2. Deleting records:
We have required that the client calls lock() before invoking delete(). However, since the record will have been deleted, there is no need to call unlock() after delete() returns.



So what happens if two clients try to gain the lock simultaneously - one to do a delete and one to do an update? If the delete gains the lock first, and it is never unlocked, will the client who wanted to do the update stay in wait state forever?

If you do unlock the record, then you must also make sure that any clients waiting on the lock will re-check that the record has not been deleted (many people seem to forget that).

You haven't mentioned what you do with your create method - doing logical record locking may not make sense, but you must be doing something there.

I agree with Frans that your reasoning behind not validating who owns the lock is not very good. I don't think it fits in with the instructions provided in the comments in the interface you were provided.

Regards, Andrew
 
Andrew Monkhouse
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Yan,

One more comment - the 44 / 80 score for locking is very common. You might be interested in reading the post "The Mysterious 44/80 Locking score". It is deliberately a bit obscure, but might give you some hints.

You might also try looking for some of Anton Golovin's posts on the subject .

Regards, Andrew
 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
you are great,because you have been passed.
 
Yan Zhou
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I did take care of multi-user scenario.

With delete(), my server internally "unlocks" the logical record, therefore, there is no need for client to do so. If a client is trying to update a record that is deleted, he will get an exception as specified in interface. I do re-check for availability of a record after getting lock.

The following is the spec. of the interface. As you can see, it says nothing that the impl. must ensure a client cannot unlock a record locked by another client. In fact, because the method signatures on update() and delete() do not take a session id, I do not see how I can track who gets the lock without extending the provided interface. My assumption is that if I have to extend/modify the interface from Sun, I might be doing more than what they wanted as many have emphasized to "keep it simple".

If my points are deducted because of not checking who is getting the lock, I would consider it as unfair.

However, I do not think I missed anything as far as locking is concerned.

 
To get a wish, you need a genie. To get a genie, you need a lamp. To get a lamp, you need a tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic