• 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

Important Locking Questions

 
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
According to my assignment specs:

Your server must be capable of handling multiple concurrent requests.



Any attempt to lock a resource that is arlaedy locked should cause the current reahd to give up the CPU, consuming no CPU cycles until the desired resource becomes available.



Does the first quote mean that I cannot synchronize any method (meaning I can use synchronized blocks, but I cannot mark any methods synchronized)? If I do that, then I could be violating this requirement, as only one thread can execute a synchronized method at a time, so this prevents concurrency.

As for the second quote, is that a hint that I MUST use wait and notify? I was thinking that if the lock is already claimed by another client, which object should have its wait method called?

Sorry but I'm very confused right now.
 
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't think there is any problem with making any of your methods synchronized.
As for the second part, I believe you are right on track about wait() and notify().
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As to the second, consider the reason the record is locked.
You're trying to update the record from 2 threads simultaneously. Do you really want the second thread entering the update routine to overwrite the changes done by the first thread?
My guess is you'd better return with an error stating that the record has been changed in the database and would the user please reload the data and verify?

Unless of course you use pessimistic locking and deny read requests as well as update requests on records that are held by anyone.
 
Liang Anmian
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You guys make sense. Yes I do agree.

Another thing. Is it silly to require locks for reading? I'm sure no, right?

Ok my last question for locking. Is it an overkill to write a deadlock detector method? What I mean is this. Supposed there is a request to lock a record. If the record is currently locked, I do not call wait immediately. Instead, I call a method such as analyzeDeadlockPossibility(). In this method, it analyzes the lock table and decides whether it is safe to call the wait method now. It is not difficult to write this method I guess. Consider this:

Client A locks record 0.
Client B locks record 1.
Client C locks record 2.

Client A wants a lock on record 1, but has to wait for Client B.
Client B wants a lock on record 2, but has to wait for Client C.
Client C wants a lock on record 0, but has to wait for Client A.

The example above will deadlock. The reason is because clients are waiting in a circular fashion. In the analyzeDeadlockPossibility method, what I can do is trace out who holds the current lock. Then from there, I trace out all the links (in this case, the links between Client A, B and C). If the link finally traces back to the same client, that means it will deadlock. So I will not call the wait method now. Instead I do a sleep on the current thread first. Then later on I try again. In order to trace out the links, what I can do is right before wait is called (assuming that this call will not result in a deadlock), I push a request object into a queue. This way, I can make use of this queue to trace out who is waiting for who.

I guess I have to make it this sophisticated in order to try not to lose marks in the locking section. As for the sleeping part, I'm not sure if this is feasible, since RMI clients may share the same thread.

Any comments?
[ February 04, 2005: Message edited by: Liang Anmian ]
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you know in advance that a record will most likely be modified after a read operation it can make sense locking it preemptively.
You could even implement an incremental locking mechanism in which you can lock a record for update only (so that it can still be retrieved in a read-only state).

The product I work on for a job does this.
We can on retrieving data from the database define whether we want that data for exclusive, update or readonly access.
In the first case a traditional lock is placed preventing any further access to that record until the lock is release.
The second allows only readonly access by other processes until the lock is released.
The last doesn't lock anything but the client retrieving the record has no authority to write it back.

Something similar could be handy here as well.
Retrieve the dataset for the table in readonly access, then when a record is selected for modification place a non-exclusive lock on it (by reading just that record again for updatable access).
 
Liang Anmian
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok I promise that this will be the last question. In the first place, am I supposed to handle deadlocks, assuming that I choose not to expose the locking methods to the client? I'm not talking about deadlocks caused by synchronization blocks. I'm referring to record locking deadlocks. Does anyone know what the locking section of the marking scheme expects?

If this is out of scope, I see no reason why I should waste time implementing it.
[ February 05, 2005: Message edited by: Liang Anmian ]
 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For your deadlock example described above, all you need to do is make sure that the Client must release any locks that it has before attempting to acquire another lock. Make it so that a single Client can only have one lock at one time. I didn't see a reason to attempt to acquire a lock to read a record.
 
Liang Anmian
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My RMI remote interface does not have any locking methods for the client. All lockings and unlockings are done automatically at the server-side. I don't want to expose them to the client, because of deadlock possibility.

Actually I was wondering why so many people want to expose them to the client. I mean, if it's controlled by the server, wouldn't we have an easier time implementing the application, since the server controls all the locking. As long as you remember to unlock the records before the methods return, there's no way for a deadlock to occur. By unlocking before any of the mutator methods return, you are also indirectly allowing the client to acquire one lock at a time (indirectly because the lockings are transparent to them).

Am I missing something? Don't tell me it's illegal to make the client a "thin client"?
[ February 05, 2005: Message edited by: Liang Anmian ]
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Liang Anmian:

Am I missing something? Don't tell me it's illegal to make the client a "thin client"?

[ February 05, 2005: Message edited by: Liang Anmian ]



It's not "illegal" to implement a thin client model. People have passed doing it that way.

The reason I chose the "rich" or "fat" client was that I had first implemented the thin client and found it wanting. It doesn't really address the problems this assignment has presented, it more or less side steps them. I don't believe it fulfills the requirements and if I were marking, I probably would fail thin clients because of the requirement for "a traditional client-server system", and the description of the server as "a data access system". I certainly couldn't justify that design in my own choices document.

In a thin client model the server would be described as a "business server" not a "data access system".

The requirement for the user interface to be "designed with the expectation of future functionality enhancements" also argues in favour of a rich client, since the thin client requires changes to both the client and the server to make any enhancements while the rich client only requires changes to the client.

Finally a true thin client would run under a browser, and would not require any dedicated client. This is explicitly forbidden.
 
Liang Anmian
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, but if I were to change to the fat client model, why will future enhancements affect only the client and not the server? Maybe I have misinterpreted or something? What kind of enhancements only affect the client?

But fair enough. I think your justifications are reasonable. It's time to change my system. I don't want to risk failing.
 
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Liang Anmian:
[QB]Sorry, but if I were to change to the fat client model, why will future enhancements affect only the client and not the server? Maybe I have misinterpreted or something? What kind of enhancements only affect the client?[QB]



Liang,

Your instructions probably only require you to provide functionality to book a record (contractor or room, depending on which assignment you have). Imagine that later on you also must add functionality to clear a booking. If you have the fat client model, you can do this by adding such functionality only to the client, using the server's lock, read and update methods that you already used for the booking functionality.

If you use the thin client model, you will need to add a "clear booking" method to the server AND you need to add functionality to your client that will call this method.

Frans.
 
Liang Anmian
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok you make sense here. Thank you very much. You have been of great help to me. Now I guess I will have to scrap my current design and redo the whole thing again. I don't mind it, since I don't want to risk failing.
reply
    Bookmark Topic Watch Topic
  • New Topic