• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

lock and unlock idea, need critics!

 
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am now at the point to implement the locking and unlocking mechanism of my program. This is the idea I have and I wonder if it's any good. Whenever a client modifies a record (say record 3), it would write a file with the record number written to it (3). Any other client that tries to modify that record (Record 3), it would check for that file exists. If it does exist, it would scan through the whole file for that record 3 (just look for number 3). If the number is found, the client either has to wait or be informed that the record is locked. On the otherhand, if the record is not found, lock it (writing record number into the file). Does this make sense? What are possible overheads?
As a design question on the side, should the client wait or be informed by the server when the record is locked?
 
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Hung,
I don't think using a file is a very elegant way of doing this. Personally, I plan on using one of the containers in the Collections API in java.util. I haven't decided yet but am considering HashSet. You could then check to see if your Collection already contained a lock on the requested record and if so you could wait() for the lock to be released. Of course everytime a lock is released, you'll need to notifyAll().
As for your second question, the instructions said that if the lock was not currently available then the method should block. I take that to mean that the client should wait until the it owns the lock. Should the client wait forever? That's something else we have to decide on.
Hope this helps
Michael Morris
 
Hung Tang
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply michael... i have one more question... how did you test your lock/unlock ? I've tried creating tons of threads to use my bookflight() method which uses the lock/unlock method but it doesn't seem to work properly. I'm not too familiar with threads maybe I'm missing something here. Maybe you have a better means of testing it out??
Thx
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Hung,
I have'nt implemeted my locking mechanism yet but there was a thread here yesterday about testing. Mark told everyone how he did it and it looked like a good way to do it. I'll go thru the posts on lock and unlock and let you know if I find it.
Hope this helps,
Michael Morris
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi again Hung,
Here's the thread:

[url=http://www.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=25&t=002159]http://www.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=25&t=002159


Michael Morris
[ March 23, 2002: Message edited by: Michael Morris ]
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I don't think using a file is a very elegant way of doing this. Personally, I plan on using one of the containers in the Collections API in java.util. I haven't decided yet but am considering HashSet. You could then check to see if your Collection already contained a lock on the requested record and if so you could wait() for the lock to be released. Of course everytime a lock is released, you'll need to notifyAll().


Hi Michael,
I was also thinking about solving this issue with a wait()-notifyAll() combination but I c
 
Nico Vanoppen
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oops,
accidently sent my message.
As I was saying :
I can't figure out how to manage this.
Please correct me if I'm wrong :
Before you can call wait() you'll have to own a lock on an object, right ?
Which object ? The Data object ? If so, you have to wait until no other thread is reading, writing, modifying ... using the Data object, because all these methods are synchronized. Doesn't seem very efficient to me.
Besides that, if the record number isn't in the set of locked records, you're locking the Data object for all other threads, right ? I think we shouldn't block the way for threads that are interested in other record numbers, should we ?
I think if we work it out this way we shouldn't bother lock/unlock because the hashset assures us that no other thread is treating the record we're interested in...
Should'nt we provide an object per record (some sort of ticket) on which we can apply the wait()-notifyAll() combination ? In this case we're not blocking threads that are interested in other records.
As you probably can see, I'm not that strong in threads, but I'm just giving you my thoughts.
Hope to read a reaction soon, thanks
Nico
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Nico,
I haven't started implementation on locking yet but I agree that if we make the lock and unlock methods synchronized in the Data class, which is what would be necessary to use wait() and notifyAll() (ie grab the lock on the Data object), then as more clients connect our performance starts to tank. In our implementation class for the RemoteDatabaseAccess interface (or whatever you call it) we could simulate a block with a loop that doesn't break until the lock on the record becomes available [ ie while(%lockIsUnavailable%) ; ]. Of course that would mean we would have to either change the signature on lock() to return a boolean or thru some sort of indirection check the HashSet in a different method (or object). I have seen some threads here on a LockManager class but am not sure how it is implemented so before I make my final decisions on locking, I'm gonna do a search on that and see how others used a LockManager.
As for using synchronized blocks, everything that I have read on the subject says that synchronizing on an object other than "this" is risky because of an increased probability of deadlock. After all if the object you synchronize on contains synchronized methods that use wait(), you can see how easy it would be to deadlock.
Hope this is helpful
Michael Morris
[ March 24, 2002: Message edited by: Michael Morris ]
[ March 24, 2002: Message edited by: Michael Morris ]
 
Nico Vanoppen
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,
Thanks for your reply !
I think your "loop solution" will easily solve this problem but I don't understand why you should change the return type of the lock method; as it returns the lock is achieved, isn't it ?
Another question flashing thru my mind : If modify() is synchronized, won't this mean that you never can have more than 1 element in the hashset ? The first thread who can place it's record number in the set will block the Data object by calling the synchronized modify method and thus prevent any other thread to even invoke the lock() method.
Please correct me if I'm wrong..
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Nico,
What I was thinking was that if some proxy class calls lock() on behalf of the client, since the lock() signature is currently:

then how does the proxy know whether it obtained the lock if we are not going to wait() in the lock() method? Now if lock()'s signature were:

then lock could return immediately and proxy could do something like this:

Anyway, I'm not saying that this is the best way to do this and if we use a HashSet inside the lock() method, we're still going to have to synchronize lock() but with a lot of clients vying for locks that should improve performance and remove another potential deadlock.
Michael Morris
 
Nico Vanoppen
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,
If you place the loop inside the lock() method you don't need to alter the signature :

where is some Collection. (I've made an abstraction of primitives and objects in the privious snippet of code.)
When you return from the lock()method you're sure the requested record is locked.
Don't you think that making the modify()-method synchronized will block the collection for other threads, as I priviously stated ?
Nico
 
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
------------------------------------------------
Nico Vanoppen
, because all these methods are synchronized. Doesn't seem very efficient to me.
Besides that, if the record number isn't in the set of locked records, you're locking the Data object for all other threads, right ? I think we shouldn't block the way for threads that are interested in other record numbers, should we ?
I think if we work it out this way we shouldn't bother lock/unlock because the hashset assures us that no other thread is treating the record we're interested in...
Should'nt we provide an object per record (some sort of ticket) on which we can apply the wait()-notifyAll() combination ? In this case we're not blocking threads that are interested in other records.
------------------------------------------------------------
hi Nico,
i have the same problem.
1. if all the methods are syn. then why we need use of HashSet in lock/unlock?
2. in any case, if object is same and all the methods are syn. then operating on single record means blocking all the threads or you can say locking all the db operations.
if we treat record as an object, perhaps this can help to achieve record level locking? but i am not sure how to implement the process.
only words are diff. but problem is same. any idea to solve the problem, pls. discuss.
regards,
sanjeev.
 
Nico Vanoppen
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,

1. if all the methods are syn. then why we need use of HashSet in lock/unlock?
2. in any case, if object is same and all the methods are syn. then operating on single record means blocking all the threads or you can say locking all the db operations.


1.Look what happens if you don't use lock()-unlock() :
Suppose the number of available seats in a record is 10 and that client A and client B are both willing to alter this record. Since A is first it will block the Data object by reading in the record in a synchronized manner, so B has to wait its turn. A reads that there are 10 seats available and releases the Data object while exiting the synchronized method. Now B gets permission to read. B also reads 10 available seats. Suppose that while B is booking f.e. 3 seats A has finished booking 2 seats writing the updated record, again synchronized. By now, B wants to write its altered record but has to wait 'til A has finished. Ok, A has finished leaving 8 seats available. Now B gets to writing the altered record still assuming there were 10 seats available and ending up with 7 available seats instead of 5.
So you need a mechanism to avoid that between reading and writing no other thread can interfere.
2.I totally agree this but I'm still not sure if this statement is correct.

Nico
 
sanjeev mehra
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Nico,
i have no doubt about the importance of lock/unlock. my point(1st one) was why to store the locked record in collection API say HashSet. in all the messages regarding lock/unlock in the forum, everyone stores the locked record in the HashSet and before notify delete the record no from the HashSet. i didn't get the importance of the storing the record no. in HashSet.
regards,
sanjeev.
 
A "dutch baby" is not a baby. But this tiny ad is baby sized:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic