• 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

How to lock or unlock??

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can anybody help me on how to lock or unlock the record.
 
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rahul,
Keep a collection of locked record numbers, together with some identifier for the client that holds the lock.
jply
 
Rahul Sri2K3377
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks jply for the info.
Actually I was thinking of maintaining an array of size = no. of records. Then whichever record is to be locked, i set the value as LOCKED at that index(and set it as UNLOCKED later). Now if anybody tries to lock an already locked record, he waits in a loop until the record he is trying to lock is first unlocked.
But, the issue here is there may be n-clients waiting in a loop to lock a record. When this record is unlocked, those n-clients try to lock it simultaneously. Thus mechanism fails.
How do I take care of this, or any other better way to lock/unlock it.
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rahul,
<code>lock()</code> shouldn't sit in a busy loop - that's wasteful. The method should <code>wait()</code>. Which client in the wait set gets a recently unlocked record will be random, unless you invent a queueing mechanism (I didn't go that far).
Remember also that it's not enough to know if a given record is locked; you have to know which client locked it because only that client is to be given access to it. This means your collection must hold something more than just a locked/unlocked flag.
About using an array - arrays have fixed size. What will you do if a record is added at runtime?
jply
 
Rahul Sri2K3377
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks jply.
Actually using Array was just a thought. And, if you can somehow control that only one client can have a lock on a record then, you really don't need to store the client info(Overhead).
Anyways, but, what you say does makes sense. I think I should also store Client Info. Now I can do it. This becomes easy if you store Client Info.
Thanks a lot once again.
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rahul,
Glad to be of help, but one of us is missing something. I think keeping track of the client is necessary, not optional. Consider the situation if you don't keep track of clients:
  • Client A locks record 42.
  • Client B tries to modify record 42, but can't - that's OK, because he didn't lock it.
  • Client A tries to modify record 42, but the server can't tell him from any other client. The server only knows the record is locked, so client A isn't allowed to modify it either. This is not OK.
  • Client A gives up, and like a good citizen tries to unlock record 42.
  • Once again, the server can't tell who's trying to unlock the record, and only the client that locked a record is allowed to unlock it. The record stays locked forever. Bad thing.

  • Am I missing something?
    jply
    P.S. Even if you allow only one record to be locked at a time, the scenario above still applies.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Guys,
Refer to Jerry's message.
As for each client, lock is always executed before unlock, what I am thinking is, the server doesn't need to know who locks it.
for one client, it works this way:
the_collection_of_locked_record_numbers;
lock()
{
if (the number is in the_collection_of_locked_record_numbers)
{wait();}
(synchronized the_collection_of_locked_record_numbers) add the number in
the_collection_of_locked_record_numbers;
}
....do something here....
unlock()
{
remove the number from the_collection_of_locked_record_numbers;
notify();
}
Am I right?
Thanks,
Paul

[This message has been edited by Paul Liu (edited November 04, 2000).]
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Paul,
You've exposed an unstated assumption in my logic. You're trusting all clients to call <code>lock</code> before modifying anything, and I'm not.
If the database were special-purpose (say, if it implemented a flight reservation schema, to pick a random example) then you could assume that the client you write might be the only one ever written. But the database server is quite general-purpose, and the only implementation of a specific schema is at the client (and the input to the conversion tool). Given this, I think it's reasonable to expect that the database could be used for other applications whose clients might not obey the rules.
Short answer - the server is a lot more robust if it tracks clients and requires a client identifier for each method that modifies data.
jply

[This message has been edited by Jerry Pulley (edited November 05, 2000).]
 
Rahul Sri2K3377
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I think I have a better solution to share with you.
First the unlocking part.I think that whenever a client wants to unlock a record, it checks whether he has locked it or not. If it was this client who has locked the record then, allow him to unlock.
Now, whenever a client wants to lock a record ask him to stand in a queue. He then waits() in a queue until his turn comes. His turn will come only when all the clients in the queue before him, has locked and then unlocked that record. Now that he has his turn he can easily lock that record, modify it, and unlock it.
Note :
1.) This scenario will hold for every record to be locked/processed/unlocked. i.e. for there will be a queue maintained for every record.
2.) Some sort of Client id is stored in the queue.
I think this should work. If I am wrong somewhere, please correct me.
Thanks and Regards,
Rahul Sri.
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rahul,
The directions for my assignment said "The lock method should block until the requested lock can be applied", so that'll work. It's simpler to have <code>lock</code> call <code>wait</code> and <code>unlock</code> call <code>notify</code>, but your solution has the advantage of granting locks in the order they were requested.
jply
 
Rahul Sri2K3377
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi jply,
Even your solution will work fine, its just that I had a thought, that , why not implement it this way.
Anyways, what you said earlier regarding that, what will happen if any client tries to modify without locking/unlocking. Good point. Yes, this may happen but, you see, it is we who are writing the clients, so we should not do it that way. Keeping in mind the future use, if you want to do that, then we have to modify the DB structure to store some kind of a flag which will have a ripple effect on all the methods given to us precoded. Is it desirable to modify all such methods??. What do you say??.
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rahul,
I don't want to go too deep into specifics, after all this is a design test as much as anything else. I'll just note that it's not necessary to modify the methods of the <code>Data</code> class to track clients. I eventually came up with an RMI-based solution that presents the interface of the searchable subclass of <code>Data</code> (with no changes to method signatures) to the client and uses client-specific write locks with timeouts ("optimistic leased locks") in the remote server. In the local case, the client still operates on the same interface but the object that implements it is an actual instance of <code>Data</code>'s searchable subclass. This arrangement involves 1 new interface and several new top-level and inner classes to accomodate the locking scheme I wanted - robust locking with no change to <code>Data</code> method signatures. I didn't even have to modify <code>Data</code> to implement the interface - I did that to its searchable subclass. That class doesn't override any <code>Data</code> methods, it just adds <code>criteriaFind</code>.
OK, I probably went a little further than necessary, but it was fun and testing is going OK. I'm even thinking of adding queuing behavior to the locking, as you suggested. Got to be fair to all those clients out there.
As for us being the only people ever writing clients for our systems, that's probably true in this case. But one thing I've learned is that working code never dies, even bad working code, so it's better to build robust systems at the outset with extensibility and reuse in mind.
jply
P.S. What about searching algorthms? I'm using a simple linear search, but thinking about making hashtable- or tree-based indexes. Sun did say efficiency was a criterion for the search function.
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Can anybody give me the template code for lock and unlock?Thanks Seshan
Hi,
I would be greateful if anybody could provide me with the sample code for locking and unlocking a record
Thanks
Seshan
Actually using Array was just a thought. And, if you can somehow control that only one client can have a lock on a record then, you really don't need to store the client info(Overhead).
Anyways, but, what you say does makes sense. I think I should also store Client Info. Now I can do it. This becomes easy if you store Client Info.
Thanks a lot once again.


 
Ranch Hand
Posts: 1874
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry for raining the parade, but I must remind 'Rahul Sri2k3377 ' that PROPER NAMES ARE NOW REQUIRED!!
Please Read the JavaRanch naming policy for more details.
www.javaranch.com\name.jsp
Javaranch appreciates your cooperation to comply with the official naming policy.
Please reregister with prper last name & help maintain the decorum of the forum.
YOUR FRIENDLY BARTENDER
SHAILESH.
 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jerry,
I think I understand when you say that there is an RMI based solution to distinguish between different clients that does not not require you to change the signature of the lock or unlock methods.
But are you able to distinguish between two different clients running on two separate JVMs on the same host ?
Your reply is greatly appreciated.
Deb
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Deb,
Yes, by using a separate remote object for each client. The remote objects' identities serve as client identifiers.
Jerry
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why does unlocking and locking a custom database even appear on the exam? Writing a database is no small task. Java provides an api for accessing databases(JDBC) but it sounds like Sun wants a Java developer to know how to write a DBMS from scratch. Why don't they just test a developer's knowledge of the JDBC by access a professional quality database? In the real world, an application would make use of an Oracle, SQL Server, or even an Access database.
 
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jerry,
What happens to the RMI-based scheme in local mode?
I created an ArrayList of "lock" objects that contains a boolean "locked" variable, a Thread reference, and a "lock"; this is created when the "Data" object is created according to the number of records; it is added to when a new record is inserted. My current implementation of "lock" has the requestor check the locked status; if it's the first in, it gets the lock and places a reference to itself in the Thread variable; it is synchronized on the lock object. When other requesters come in, they wait on the lock object. Of course, there's no assurance that the lock will be granted on a FIFO basis, but I can't figure out how to assure that, because the JVM will decide who gets the lock object next.
Just some thoughts...
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Douglas Kent:
What happens to the RMI-based scheme in local mode?


Douglas,
you do not need locking for local mode access since you do not have any concurrency...
Surely the case where 'several users simultaneously access a local database from different JVMs on the same machine' is not worth considering !?
Regards,
Marc
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry,
that naming policy wasn't on here when I registered last time
round.
Regards,
Marc
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Douglas,
I agree with Marc that locking isn't necessary in local mode. I built the client with an adapter class that functions differently depending on whether you plug in a Data object or a remote reference to the server proxy class, but always presents the same interface to the GUI.
About random order of granting locks, I decided to put up with that. I figured that a database lock/read/modify/unlock cycle was brief enough that no client would have to wait too long unless there was a huge number of them, and in that case I'd have other problems. There are ways to arrange for fairness in choosing the next thread to run from group of waiting threads, see Concurrent Programming in Java 2nd ed (Doug Lea), pp. 227-228.
Jerry
[This message has been edited by Jerry Pulley (edited January 24, 2001).]
 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Guys,
The following is part of the comment block for the lock method.
" If the argument is -1, lock the whole database. "
Let us assume that client A issues a call to the lock method with -1 as argument (record number). It is possible for some of the records to be already locked by other clients at that moment.
How can client A lock the entire database(I mean all records)?. Does he have to wait indefinitely till he gets all records available for locking?.
i would appreciate your comments on this.
Thanks
 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ,
Yes, It is possible for some clients to be blocked while the -1 db lock is requested. You have the choice of waiting till all locks are released or you can treat it as an administrative function which locks out all new lock requests and lets the existing locks to finish. But be sure to document your approach and assumptions. Just my opinion. Any comments from certified developers?
With warm regards
Abhijeet

Originally posted by Ajit Kumar:
hi Guys,
The following is part of the comment block for the lock method.
" If the argument is -1, lock the whole database. "
Let us assume that client A issues a call to the lock method with -1 as argument (record number). It is possible for some of the records to be already locked by other clients at that moment.
How can client A lock the entire database(I mean all records)?. Does he have to wait indefinitely till he gets all records available for locking?.
i would appreciate your comments on this.
Thanks


 
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jerry, I do not see the reason why we do not need to take concurrent access into consideration for local database connection. In my opinion, the server itself can also be a client. We can have this scenario:
1) multiple remote clients accessing server's A database
2) server A itself is also a client accessing its local database
Now, this sceneario is different from running multiple client with different JVMs on the same machine.

------------------
 
Ranch Hand
Posts: 318
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jerry,
You assume that the clients will NOT lock and unlock. However, couldn't a person justify doing the lock and unlock on the client side? For one, you don't have to track client i.d.'s and the lock and unlock methods are declared public why else would they be public unless it is reasonable to assume they are that way to give the client access to them. I think it's fair to say that you didn't want to assume that the clients would do this, but it seems equally justifiable to say you don't want to track client i.d.'s and you felt that lock and unlock were public so, why not call them from the client. Both seem reasonable to me.

With Respect,
Matt
 
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just a thought.
If you handle locking on a client then what happens in the following scenario
1. Clients Locks record
2. Client crashes
The record is locked with no way to unlock it.
 
reply
    Bookmark Topic Watch Topic
  • New Topic