• 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

record lock & lock timeout

 
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,
I have read a number of discussion about locking and lock timeout. Some people are right in saying that a concept of lock timeout should be implemented as a standard feature of any database server. I have some doubts regarding that. Please comment.
Suppose the server I have created is redesigned and a concept of lock timeout is coded into it which enables the server to keep track of the time at which a record was locked. Once a time limit of say xx seconds is is crossed the server successfully releases the lock and other clients can now operate on the record concerned. Looks simple isn't it.
As we all know that the current implementation of add, modify, delete methods in the Data class which modify the database physically, do not bother to check whether the client which is invoking them has attained a lock on the record or not. So as we can see that it is not neccessary to lock a record to access these methods. The concept of lock > read > modify > unlock is supposed though not emphasised to be used while accessing these methods.
Now here the problem starts, suppose client A locks record number 10 and something goes wrong with it that prevents it from doing any further request of read, write, unlock to the Data class. Meanwhile the server on sensing that record number 10 has been locked for more than xx seconds, releases the lock and allows Client B which was waiting, to lock the record 10. At this very point the problem on the side of Client A got resolved and it was able to
pass a read > write request to the Data class, thinking that it had obtained the exclusive lock on record 10. Since the write/modify/add/delete methods do not check whether the record being modified by client A is locked by client A or not, the client A is able to modify the database without any hiccups even when it does not has a lock on the record !!!
This can easily lead to data corrption and further towards extreme chaos.
This scenario can happen on implementation of timeout on the server level. So what I want to say is that on implementation of timeout faclity on the server side, one has to design another facility to make sure that only a client which has a lock on the record is able to modify it. This requires extensive redesign of the methods in the Data class to implement this sort of fine grained security and I feel that it is out of the scope of the project.
Any suggetion..
Thanks,
Vishal Sinha,
 
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You clearly made the case to have the LockManager class. As you mentioned, there are two parts to the locking.
1) You need to manage the access to locking/unlocking/modify/delete via a LockManager on the server side.
2) You need to block the calls to prevent data corruption in the Data calls using synchronized and wait()/notifyAll().
You need to do both for this assignment. I don't think it is out of scope.
 
Abhinav Anand
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi,
Please elaborate about the LockManager class and how to block calls to the Data class's methods like add through a lock manger.
Thanks,
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
LockManager takes care of managing access to lock/lock/modify/delete functionalities. You need to make sure that every client cannot unlock a record which is locked by some other client. This is done in the LockManager. It is better to implement this functionality in the LockManager instead of individual remote objects.
Also read about other posting on Connection objects. Basically, you need to create an unique instance of a remote object for every client.
[ May 04, 2002: Message edited by: Sai Prasad ]
 
Abhinav Anand
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Alright I got your point. I am searching this forum for the connection objects business. I will keep you posted on the developments.
Thanks,
 
Abhinav Anand
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I looked up some threads on connection object, but I really cannot understand the need to do the same thing in a different class when they can be so effectively handled by the Data class itself.
Any suggetions are welcome
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Vishal,
You are binding the Data instance to the RMI Registry and serve the client requests using only one instance of the Data class per table.
Connection factory and connection object design is valid if you want to do the things below:
1) Don't want to create a client id at the client since it is the job of server to keep track of clients.
2) You have a code in the client to lookup and connect to the server when the server is shutdown and restarted without restarting the client. Now your design creating client id at the client may fail.
3) Every time when a new method is added to the Data class, the programmer has to remember to add the client id in the parameter of the method.
4) If you want to restrict access to some of the clients in the future using RMISecurityManager. In your design, you have to put the access control
code in the Data class which is not the right place to manage security.
I may have missed out somethings but I feel by using ConnectionFactory, Connection and LockManager, you are distributing the different functionalities to various classes. It sounds more object oriented to me.
 
reply
    Bookmark Topic Watch Topic
  • New Topic