Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Modifying Lock / Unlock ?

 
Gurpreet Saini
Ranch Hand
Posts: 295
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi reader,
Can I modify lock / unlock to lock(clientID, record) , unlock(clientID, record) ?. I certainly need to change them. Moreover, if I do how many points I might loose ?.
Thank you,
 
Michael Morris
Ranch Hand
Posts: 3451
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Gurpreet,
If you use a lock manager and plan to map clients to locks then those methods should have the signature you indicated. There is no need to change the signature in Data or your interface into Data. When a client calls lock(record), then your remote implementation just passes that on to lockManager.lock(this, record). You don't even need to implement lock and unlock in Data.
Hope this helps,
Michael Morris
 
Gurpreet Saini
Ranch Hand
Posts: 295
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Morris,
My client is not calling lock(record). Also, I am not implementing lock / unlock in my Data class. I am implementing in the DataAccess extends Data. I also, do not want to change the signatures of lock / unlock, but on server side there is considerable strain for monitoring unlocking .

Thank you,

[ August 24, 2002: Message edited by: Gurpreet Saini ]
 
Michael Morris
Ranch Hand
Posts: 3451
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Gurpreet,

Also, I am not implementing lock / unlock in my Data class. I am implementing in the DataAccess extends Data.

What I said still applies. You don't have to implement lock / unlock in Data's children either, if you use a lock manager. If you are not calling lock(record) from somewhere on the client then how are you locking records?
Hope this helps,
Michael Morris
 
Jack Yang
Ranch Hand
Posts: 59
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Micael,
quote
-------------------------------------------------
What I said still applies. You don't have to implement lock / unlock in Data's children either, if you use a lock manager. If you are not calling lock(record) from somewhere on the client then how are you locking records?
--------------------------------------------------
I think he means client just calls modify method in the remote interface,and the remote method runs
lockmgr.lock,db.modify and lockmgr.unclock.I think this is ok,right?I read some threads you metion about client side need to call lock/unlock.Is it necessary?
 
Nate Johnson
Ranch Hand
Posts: 301
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is how mine works... my client (the RemoteData in this case) asks my facade to book a seat. The facade calls lock, which asks the RemoteData to lock which in turn asks the LockManager to lock the record. Then the facade reads the row to be sure that there are still enough seats. Then if still ok, modifies the row and calls unlock.
I dont know if this helps at all, but just wanted to throw it in there Basically what I wanted to say was that RemoteData doesnt really need to be calling modify or anything like that on the Data object.
 
Michael Morris
Ranch Hand
Posts: 3451
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jack Yang:
I think he means client just calls modify method in the remote interface,and the remote method runs
lockmgr.lock,db.modify and lockmgr.unclock.I think this is ok,right?I read some threads you metion about client side need to call lock/unlock.Is it necessary?

As far as I can tell, there is nothing wrong with doing it that way. Any reasonable design that accomplishes the task is always OK. The way I did it is just one of many.

Originally posted by Nate Johnson:
The facade calls lock, which asks the RemoteData to lock which in turn asks the LockManager to lock the record. Then the facade reads the row to be sure that there are still enough seats. Then if still ok, modifies the row and calls unlock.

Did you copy off my paper?
Michael Morris
 
Mark Spritzler
ranger
Sheriff
Posts: 17276
6
IntelliJ IDE Mac Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gurpreet.
Please try to refrain from duplicate posting. I deleted your duplicate post on this same subject. Luckily no one had responded so you didn't lose any information.
Next time, just reply to your own post so it will put your thread to the top of the list.
Mark
 
Gurpreet Saini
Ranch Hand
Posts: 295
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi company,
I am very sorry again not answering you guys on time. What shall I do if phone line does not work ?. Yes, morris I do not call lock / unlock directly from client. I also do not call modify from client side. Your quote once said if you remember it was "do not give expose to public methods (Data class) to clients" . So, with my design I hide all the public methods from client. If attempt is made then also not possible. Now, I am about to test my unlock method .
Thank you,
 
mala murthy
Greenhorn
Posts: 1
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I am still in the process of figuring the best way to implement lock/unlock. Need your help in deciding if it OK to sychronize lock/unlock methods or is it better to synchronise the method say bookseats()that calls lock/modify/unlock assuming that bookseats() is an added method in the subclass that extends Data class.
My knowledge of java is very limited. So pl. excuse me if my questions sounds too dumb.
Thanks a lot in advance
Mala
 
Thomas Fly
Ranch Hand
Posts: 164
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try Implementing Lock/Unlock
 
Michael Morris
Ranch Hand
Posts: 3451
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi mala_murthy,
First, Mark is probably going to tell you to change your display name to a first and second name. So you might as well go ahead and do that.
Next, there are no dumb questions, only dumb candidates whose pride and ignorance doesn't allow them to ask whatever question they need an answer to.

Need your help in deciding if it OK to sychronize lock/unlock methods or is it better to synchronise the method say bookseats()that calls lock/modify/unlock assuming that bookseats() is an added method in the subclass that extends Data class.

You'll almost have to synchronize lock and unlock if you don't want a busy wait. In other words, if you are going to call wait() in lock() when a requested lock is already owned and notifyAll() in unlock() when locks are released, then you must synchronize those methods.
You could avoid synchronizing lock() and unlock() by synchronizing on the collection that holds the currently locked records, but I have really never seen the benefit in doing it that way.
If you synchronize your bookseats() method instead, how do you know when to wait()? You will have to have some knowledge of currently locked records to control it there. Also, by not synchronizing lock() and unlock() you have doomed all future developers on the project to take your approach to protecting the database from concurrent access, ie they can't just call lock() and unlock() for new features.
Hope this helps,
Michael Morris
 
Mark Spritzler
ranger
Sheriff
Posts: 17276
6
IntelliJ IDE Mac Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Morris:
Hi mala_murthy,
First, Mark is probably going to tell you to change your display name to a first and second name. So you might as well go ahead and do that.

"mala_murthy"-
Welcome to the JavaRanch! Please adjust your displayed name to meet the
JavaRanch Naming Policy.
You can change it
here.
Thanks! and welcome to the JavaRanch!
Mark
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Morris:

You could avoid synchronizing lock() and unlock() by synchronizing on the collection that holds the currently locked records, but I have really never seen the benefit in doing it that way.

I guess there are two major point of views on this issue. Do you prefer the (minimal) performance increase of not synchronizing the whole method, or the improved clarity of your API ("synchronized" not hidden within a method).
 
Michael Morris
Ranch Hand
Posts: 3451
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Lasse,

I guess there are two major point of views on this issue. Do you prefer the (minimal) performance increase of not synchronizing the whole method, or the improved clarity of your API ("synchronized" not hidden within a method).

Before answering that I should qualify my statement by saying as pertains to this assignment. Actually you take a performance hit by synchronizing the method but the intent is clearer. It really depends on several factors. In the case of lock() for this assignment, it really makes no sense to synch the Collection instead of the whole method because you are only allowing 5-10 lines of code to accessed concurrently before everyone hits the turnstyle. So you don't really get much of a performance boost in that case. Of course by synching the method you stop access to the rest of the object's synchronized methods too which could cause a significant performance problem. Once again, in this assignment that should not be a severe problem.
Now on the other hand, if you have a large pool of clients accessing many synched resonably long methods, then it might be necessary to take a look at synching the data instead. That's always a dangerous proposition though if there are references to data outside the class.
So all in all, I prefer synching methods to synching objects.
Michael Morris
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic