Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

lock()/unlock() again ...

 
Suresh Bansal
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Just a few points.
1. Requirements say, that we should allow for locking the whole database. But there is no mention on unlocking the whole database once it is locked. So, should be just mention this and not implement it ?
2. When we call write() from client, should we check on the server, if the client holds lock to this record ? or we assume that the client never calls a write() with out calling lock().
Thanks,
Suresh.
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, should be just mention this and not implement it ?
You need to implement the unlock(-1)
When we call write() from client, should we check on the server, if the client holds lock to this record ?
Yes. You shouldn't allow any client to modify the data unless it is locked by that client.
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sai wrote:
You need to implement the unlock(-1)

I have not implemented unlock(-1). First, I didn't see that in the requirements, and second, the javadoc for lock() clearly asks for lock(-1), while the javadoc for unlock() is silent on the issue.
I think we all agree that lock(-1) is for mainanance, and onece it happens, the server goes down, so there is no need for unlock(-1).
Just my opinion,
Eugene.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I did not have unlock(-1). It was not in the requirements, and I see lock(-1) as the process for maintenance or server shutdown, in both cases a server shutdown is in order, and you need to lock all the records so no client can cause corruption.
Mark
 
Suresh Bansal
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Thanks for your views.
1. That is right that the functionality of unlock(-1) is not asked for in the requirements. We can implement it (also it will be less code to add) or may be just mention in the document.
2. Say if the client directly calls write (as the full api is exposed to client) without a call to lock. Then should we check at server end that the client holds the lock for that record. If yes, then this will require signature change for write method as we need to pass client id also in the write ?
Thanks,
Suresh.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
2. Then don't have the client call write directly.
If you have something like a Facade, then the only acces the client will ahve is through this class, then in that class you determine and make sure that write does not get called unless it first locks the record.
Mark
 
Chiji Nwankwo
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Regarding the unlock method. Can we enforce some form of turn taking by using the notify() instead of the notifyAll() method? Due to the fact that calling notify will make sure that the next client to obtain a lock on the object will be the next one that will be woken up.
I am aware that you can't guarantee which thread will obtain the lock first, but is it not possible, once the lock has been obtained to make sure that we notify the next client(the one with the lock on the object) in the queue?
Please comment on this.
Thanks,
Chiji
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic