• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking the whole database

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,
I am interested in knowing what to do when a client calls lock(-1, remoteData).
Lets say the following things happen
client A ---> calls lockManager.lock(5,clientID)
client B ---> calls lockManager.lock(8,clientID)
client C ---> calls lockManager.lock(-1,clientID)
client D ---> calls lockManager.lock(4,clientID)
client E ---> calls lockManager.lock(6,clientID)
client A will be able to lock row number 5,
client B will be able to lock row number 8,
client C should wait since A & B are holding locks
Now what should client D and E do? Should they be allowed to lock the respective locks? Or they should wait for the time being? Until how long should they wait. Do I have to have a time limit on how long should they wait? Also what kindda message should I show to the client if this occurs.
Thank you for your help!
-Amish
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually the client shouldn't call lock(-1). Only the server should call lock(-1) when the server is to shutdown.
Mark
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So Mark, What would the client ID be if server calls the lock(-1). I have a LockManager which has a lock method which gets two paramter. One is the rowID and other is client ID.
If server decides then I would assume that no clients should be allowed to lock any more records. Am I correct?
Please reply!
-Amish
Originally posted by Mark Spritzler:
Actually the client shouldn't call lock(-1). Only the server should call lock(-1) when the server is to shutdown.
Mark
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Amish Patel:
If server decides then I would assume that no clients should be allowed to lock any more records. Am I correct?
Sooo... how are you going to avoid deadlock if clients need to lock more than one record? And don't answer that the FBN client doesn't do that. Take a look at Data. It's a fully generic, fully reusable database.
- Peter
 
Stephen Gargan
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually the client shouldn't call lock(-1). Only the server should call lock(-1) when the server is to shutdown.
Mark

Looking at the spec it doesn't specify anyplace that the client can't call lock with -1 to lock the whole database. I can see why it might not be very advisable to let clients lock it but it doesn't say that its for the server only.
ste
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,
What do you mean how are you going to avoid deadlock? According to Mark only the server calls lock(-1). So my question is that since the server calls lock(-1), then new clients should not be allowed to lock records. Now old clients who have already locked records and if they need to lock additional records, I guess I will allow them to lock records. Should I be doing this?
Also nowhere in the requirements it says that server should call lock(-1). How should I be thinking about this problem? Your advice is highly appreciated.
Thanks
-Amish
Originally posted by Peter den Haan:
Sooo... how are you going to avoid deadlock if clients need to lock more than one record? And don't answer that the FBN client doesn't do that. Take a look at Data. It's a fully generic, fully reusable database.
- Peter
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All I am saying is that in my code, I am sure the client can never call lock(-1).
That can't happen in my code, and I do call lock(-1) in my close method in the server only.
Mark
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Amish Patel:
What do you mean how are you going to avoid deadlock? According to Mark only the server calls lock(-1).
Who says? Does that API say "can be called by server only"? Why does the purely-local Data expose this function? To quote my own post above, "Take a look at Data. It's a fully generic, fully reusable database."
In the FBN project, yes, only the server calls lock(-1) and even that only in some designs. IMHO, you should not make the assumption that the FBN system (or rather, the small part of the system that you are developing) is the only thing that will ever use Data or your networked server.
So my question is that since the server calls lock(-1), then new clients should not be allowed to lock records. Now old clients who have already locked records and if they need to lock additional records, I guess I will allow them to lock records. Should I be doing this?
That's one of the many design decisions you need to make. I just point out that disallowing new locks may cause deadlocks if the client application(s) ever need to have more than one lock. There are roughly three responses to that.
  • "By that time I'll have a new job / this is just a certification and there won't be any such clients." The assessor won't be impressed by your powers of reasoning in software design. It is unlikely to stop you from passing though.
  • "We need just one lock; I'll support just one simultaneous lock per client". Fine; this is a design decision, and a valid one. Document it. Maybe even enforce it in your code.
  • "I don't want to introduce arbitrary restrictions that aren't documented in the API that I'm being asked to implement. Clients may acquire more than one lock." Then you have to confront this issue head-on -- there are a number of options, depending on what you think the lock(-1) is for and whether you think it is acceptable that it might take a long, unbounded time to acquire. These options range from throwing exceptions at clients trying to acquire new locks, and taking their locks from them in the process, to patiently waiting for a moment that no single client holds a lock anymore and only then granting the database lock.
  • Your call. I'm just pointing out that there is an issue you need to think about.
    - Peter
     
    Anonymous
    Ranch Hand
    Posts: 18944
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    What will we do without you?
    Thank you so much
    -Amish

    Your call. I'm just pointing out that there is an issue you need to think about
     
    Peter den Haan
    author
    Ranch Hand
    Posts: 3252
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Amish Patel:
    What will we do without you?
    Well, without me, I guess nothing much would change -- what with Mark and Junilu and the many other intelligent voices in this forum such as Max and Eugene. In fact, without me, there might be one or two who would've been certified by now unhampered by a curmudgeon who views the SCJD as a learning experience where you get the rare opportunity to think everything through in detail and can take a stab at getting it exactly right
    - Peter
    [ February 17, 2003: Message edited by: Peter den Haan ]
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic