Hi Peng,
Do your instructions require you to allow clients to perform deletes? I think you have to implement create() and delete() on the server side, but not on the client side.
How can I delay between the lock and the update()
All you need to do is call Thread.sleep() for a few seconds between your call to lock() and your call to <whatever modification method>.
If you do this, and you have two
separate threads trying to call your modify() method for
the same record at the same time, then because of the sleep, you should be able to have one
thread blocked by the lock while the other thread is completing it's modification (it would be good to throw some debugging or logging messages into your server code so you can confirm that one thread did get blocked). Then, after the first thread has completed it's modification, the second thread should get a chance to run it's modification ... what happens then is up to your requirements - if each record can only be modified only once, then the second thread should fail to perform the modification with a suitable error message.
Just to make sure you understand: the delay is only for while you are testing your locking: when you are happy with your locking, you can (and should) remove the delay.
when I add the loop or wait() ,the actionListener in the delete button will not accomplish ,then make the System out of control.
This is a separate issue to the one you originally raised. This issue
could affect you even without the built in delay that you are currently using. I don't think you need to worry about it for the assignment (but you would have to in real life). I dont know if you want to discuss it :
now, or after you get your locking working the way you want it to work[list]or never
So the distinguish by the instance can't be aviliable.
What is the
this that you are using in the calls to lock() and unlock() then? If I understand you, it will not be unique per client, so I don't think it is serving any purpose.
And the second question is when the client is notified ,do he want to lock the num again in orde that the other who wants to modiry the same num must go in wait() when he is modifying .
Yes, upon notification, the client should attempt to get the lock.
the third question is :the unlock() is data class, when it use the notify() to notify others,
how can it knows who should be notify,I assume that one is lock(num=3),the other is lock(num 4),both them are wait;the unlock is just (num=3);
Perhaps you should look at the
notifyAll method then? Calling it will notify all waiting threads, and they can verify whether their lock is now available or not.
Something else to think about: the UrlyBird instructions have the requirement:
If the specified record is already locked by a different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked. If you don't have this requirement, then you are safe with what I said before. If you do, then strictly speaking, I don't think you can meet this requirement by having a common object on which all client's call wait() and notifyAll(), because if you do this, then a client will consume CPU cycles anytime
any lock is released, not just the lock the client is interested in. I won't go into that any further unless asked.
So I hava a idea is that when some one locks the num,others to lock the same num should be in wait(),but now I design that others the different num
also to wait(),at this time when the lockowner unlock the num,I use the notifyall(),let all in the wait() wake up to run.
That is to say :At any time I only permit one client to access the db.Is the idea aviliable?
I think that this will work since you can only do an update by calling your modify() method which ensures that the operation should be fast.
However
I personally don't think this is a good design, because it will not cope well with growth, especially as more and more user's start using the system.
Regards, Andrew