• 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/Unlock

 
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello.
I'm making the final review of my code, bu I need advise in one situation.
My DatabaseFacade class, in the methods that deletes and modify the record it does something like:

In the LockManager class I have a condition that chacks the record number and the client ID and if they are the same no lock is done. This is to prevent deadlock conditions in the reserve seats method as in this method the sequence is lock-read-modify-unlock and the read and modify methods are called from the DatabaseFacade class.
Is this design OK?
Miguel
 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My suggestion to you is that you forget about the "clientid" and adopt a simpler yet effective approach like:
Keep lock/unlock empty for the local database access. I believe (and I think that many in this forum agree) that in the local mode the locking mechanism can be ignored. I still have difficulties to justify that. I think that the scenario where local lock would apply would be with multiple threads accessing the same record.
In the remote database scenario you will probably have something like a "DataConnection" class acting as a bridge between the clients and the DataServer wich in turn provides access to the remote database file. The lock/unlock mechanism would be controled in the DataServer without taking in account any client ids. The DataConnectio's lock/unlock would keep a list of all locks granted through that instance checking that list before delegating lock/unlock calls to the DataServer. Only locks to records not contained in the list would be forwarded. Unlocking records not contained in the list would be ignored.
 
Miguel Roque
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello again.
Regarding the lock/unlock methods in Data class, i've leaved them empty (except for the check for a valid record number) as lock/unlock is something that only has to do with concurrent access to a database and the Data class provides basic local access to a database so no lock/unlock here.
My question is, should I leave the check in the LockManager class that allows the same user to lock the same record where it has the lock or should this same user wait for the unlock of the record where it has a lock?
I leave here two interesting articles on database lock:
DBMS Locking Part I (DBMS only)
DBMS Locking Part II (DBMS only)
One more thing, I've read this in a glossary of terms:

Locking is a mechanism by which database systems can prevent conflicting access to data when multiple users are making requests to the data.


Miguel
 
Marcos Motta
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

should I leave the check in the LockManager class that allows the same user to lock the same record where it has the lock or should this same user wait for the unlock of the record where it has a lock?


I dont think a user should wait for the unlock of a record that she has already locked. Just like calling synchronized methods. Once a thread takes the ownership of the monitor's lock it can call any number of methods on that object without waiting.
 
Miguel Roque
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello again.
One final question, should the methods from the DatabaseFacade be synchronized?
I make this question due to the fact that Data class is thread safe and no thread can execute a method when other thread is executing it, but in the DatabaseFacade class there are methods that call synchronized code, then call unsynchronized code and then again call synchronized code.

In this example, our thread could pause his execution after read the record and by then other thread could call the getRecord method or even the modify method, but if I synchronize the methods in the DatabaseFacade class this would not happen.

Comments please.
Miguel
[ March 17, 2003: Message edited by: Miguel Roque ]
 
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Miguel,
Did you finally chose not tio implement anything in Data? Why?
Thanks
 
Miguel Roque
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Raffe.
I've decided to go for lock/unlock only in network mode as in local mode we simply don't need it!
In the instructions received from SUN but in local mode we don't have multiple clients.
Miguel
 
Raffe Paffe
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Miguel,
Very true, but how would you do if you would make it in Data? I have no implementation i Data but i am thinking of it.
Thanks
 
Miguel Roque
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Raffe.
As far as I see, to lock/unlock in Data class you have the following choices:
1) Use the current execution thread, but this will cause problems with RMI - There are a lot of posts regarding this.
2) Don't use the client ID and trust that a new user of the class will do everything correctly.
3) Change the method signature.
4) As far as I've read, Max Habibi has some kind of soluction.
Miguel
 
Raffe Paffe
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Miguel

2) Don't use the client ID and trust that a new user of the class will do everything correctly.


You mean just lock within in Data and never use any client ID? mmm yes, this will work but you have to "trust" the client. Is that ok?

4) As far as I've read, Max Habibi has some kind of soluction.


Max, could you please comment?
 
Raffe Paffe
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Miguel

In this example, our thread could pause his execution after read the record and by then other thread could call the getRecord method or even the modify method, but if I synchronize the methods in the DatabaseFacade class this would not happen.


He cant modify the same record becuse you have a lock!!
 
reply
    Bookmark Topic Watch Topic
  • New Topic