NX: Why do you all make LockManagers?

[Mogens Nidding]

Hi!
I am wondering whether I am missing out a vital point. It seems many people have a LockManager class for record locking. Is that for clarity? I think all my locking code fits in 25 short lines!

[Philippe Maquet]

Hi Nicky,
I am not so sure that so many people here implement locking in a separate LockManager class.
If - as you tell - all you locking code fits in 25 lines only, it probably doesn't make sense at all to write a separate class for them. People who write a separate LockManager class do it because they include in their locking scheme functionalities which make their locking code a bit more complex than your 25 lines: deadlock detection (of crossed lock claims and/or crashed clients) and other funny stuff like that (but useless maybe).
And those people do it (the separate LockManager) for clarity purposes: Data simply delegates locking to LockManager. It just makes the locking code easier to read and maintain.
Regards,
Phil.

[Eric Kim]

I figured out that for my design it should be possible to just let Data class handle locking. All I need to do is to move locking code from LockManager to Data and maintain the same map.

[Mogens Nidding]

Thanks, Phil!
I think the 25 lines do the minimum required. Any idea if it would affect scoring to do sanity checks (such as whether the client who unlocks a record is the same client that locked the record)?

[Eric Kim]

My requirements actually says that client who unlocks a record must be the same client who locks the record, and it is identified by a cookie.

[George Marinkovich]

Hi Nicky,

Originally posted by Nicky Bodentien:

I think the 25 lines do the minimum required. Any idea if it would affect scoring to do sanity checks (such as whether the client who unlocks a record is the same client that locked the record)?

Do you have one of the cookie-free Sun-supplied interfaces? If so, then you're probably OK if you are making all the database operations available directly to the client and you rely on a comment to say that the protocol of lock, database_operation, unlock, must be called in the same method whenever the client wants exclusive access to a particular record. If you're only providing business methods that hide the locking from the client then you're definitely OK, since the client can't help but follow your locking protocol.

[Javini Javono]

Hi,
Locks a record so that it can only be updated or deleted by this client.
If you have that line or something like it, and you expose Data to the client,
I suspect that you must not allow another client to unlock a record that
the original client locked.
Thanks,
Javini Javono

[Philippe Maquet]

Hi Nicky,

I think the 25 lines do the minimum required. Any idea if it would affect scoring to do sanity checks (such as whether the client who unlocks a record is the same client that locked the record)?

George and Javini already have replied about the additional "sanity checks" you should perform.
Here are the relevant comments in my own instructions:
- lockRecord(): "Locks a record so that it can only be updated or deleted by this client."
- unlock(): "Cookie must be the cookie returned when the record was locked; otherwise throws SecurityException"
- updateRecord() and deleteRecord(): "Throws SecurityException if the record is locked with a cookie other than lockCookie."
In the case you'd have instructions with no cookies, it's probable that you still have a comment comparable to the one I mentioned for lockRecord() above. Of course you must perform that check.

George:
If you're only providing business methods that hide the locking from the client then you're definitely OK, since the client can't help but follow your locking protocol.

Javini:
Locks a record so that it can only be updated or deleted by this client.
If you have that line or something like it, and you expose Data to the client,
I suspect that you must not allow another client to unlock a record that
the original client locked.

I disagree with both of you.
Do you really think that an architectural decision of yours (placing your business layer server-side instead of client-side) should allow you to change the contract the data layer must implement?
Regards,
Phil.

[George Marinkovich]

Hi Philippe,

Originally posted by Philippe Maquet:
Do you really think that an architectural decision of yours (placing your business layer server-side instead of client-side) should allow you to change the contract the data layer must implement?

Of course not. The contract the data layer must implement remains the same. A client of my data layer must perform in a single method the protocol of lock, database_operation, unlock, if the client needs exclusive access to perform the database_operation of interest. This is explained in a comment contained in the Data class.
I then went on to explain that there is an architectural decision to be made as to whether locking is exposed to the client-side. Note that this is not saying whether or not locking is implemented, but rather whether the locking is exposed to the client-side. In other words, does the client-side call lock and unlock or not. Obviously if we are implementing locking on the server-side and we are not exposing locking to the client-side then the client-side does not need to be aware of the locking protocol. On the other hand, if we are implementing locking on the server-side, but we are exposing locking to the client-side, then the client-side does need to be aware of the locking protocol because in this case the client-side is using the Data class directly and can therefore be expected to follow the usage instructions (i.e., the locking protocol) explained in the Data class.
So the contract the data layer must adhere to is the same whether or not the locking is exposed to the client-side. A client of the data layer must adhere to the locking protocol as explained in the Data class. If the immediate client of the data layer is on the server-side it must adhere to the locking protocol of the Data class. If the immediate client of the data layer is on the client-side it must adhere to the locking protocol of the Data class. If the immediate client of the data layer is on the server-side, and it adheres to the locking protocol of the Data class, and further it doesn't expose locking to the client-side, then under these circumstances the client-side does not need to be aware of the locking protocol because under these circumstances it's impossible for the client-side not to adhere to the locking protocol. This is true for two reasons: 1) the client-side couldn't misapply the locking protocol if it wanted to because it doesn't have access to the lock and unlock methods, and 2) the client-side is calling business methods provided by the server-side which themselves correctly adhere to the locking protocol specified by Data because these business methods are themselves the immediate clients of the data layer.
So, if I look back to what I said:

Do you have one of the cookie-free Sun-supplied interfaces? If so, then you're probably OK if you are making all the database operations available directly to the client and you rely on a comment to say that the protocol of lock, database_operation, unlock, must be called in the same method whenever the client wants exclusive access to a particular record. If you're only providing business methods that hide the locking from the client then you're definitely OK, since the client can't help but follow your locking protocol.

it seems to me it's merely a shorter version (minus some explanation) of what I've said in this post.
To restate my point in brief: if you adhere to the locking protocol of the Data class on the server-side and if you don't expose the lock and unlock methods to the client-side, but instead provide business methods (which themselves adhere to the locking protocol), then the client-side need not be aware of the locking protocol.
[ March 16, 2004: Message edited by: George Marinkovich ]

[Vishwa Kumba]

I get the idea that both of your views are the same.
But coming to the subject of the post, just like Nicky Bodentien, I also have a simple locking strategy in my mind with similar number of lines of code. Performance wise, it may not be a good design, but as long as it works with no deadlocks and meets the requirements, will I be able to get away with it?......Would it be worth 80 points?....that's more than the number of lines of locking code that I might end up writing.
I gather from the old posts, that some people have implemented a seperate LockManager and also read-locks/write-locks, allowing concurrent access for reading records and synchronized access to writing records using Mark Grand's concurrency design patterns etc......
Have you guys heard/known anybody of passing/failing the assignment with such simple locking designs of this size. Just wanted to make sure that myself and Nicky are not the first people to attempt this

[George Marinkovich]

Hi Vish,

Originally posted by Vish Kumar:
Have you guys heard/known anybody of passing/failing the assignment with such simple locking designs of this size. Just wanted to make sure that myself and Nicky are not the first people to attempt this

My locking strategy was very simple. I did not have a LockManger class, locking was implemented in the Data class. I did not attempt to free the lock held by a client in the event of that client's death. I did not loose any points for locking. I believe it is possible to score very well with a simple locking strategy as long as that locking strategy satisfies all the requirements that are present in your assignment instructions. It doesn't have to offer superior performance, it doesn't have to offer the highest level of concurrency possible, and it doesn't have to solve problems that aren't present in your assignment instructions. Simplicity is a stated design goal of the project, performance and sophistication are not. The more complicated the locking strategy the more things that can go wrong in the implementation.

[Vishwa Kumba]

Thanks George,
That's quite encouraging. Will post my locking design for the rancher's comments, once I am happy with the design.

[Philippe Maquet]

Hi George,

Original Nicky's question:
Any idea if it would affect scoring to do sanity checks (such as whether the client who unlocks a record is the same client that locked the record)?

It's clearly a question which concerns the *implementation* of the *Data layer*, right?

Your answer:
Do you have one of the cookie-free Sun-supplied interfaces? If so, then you're probably OK if you are making all the database operations available directly to the client and you rely on a comment to say that the protocol of lock, database_operation, unlock, must be called in the same method whenever the client wants exclusive access to a particular record. If you're only providing business methods that hide the locking from the client then you're definitely OK, since the client can't help but follow your locking protocol.

Javini's answer:
Locks a record so that it can only be updated or deleted by this client.
If you have that line or something like it, and you expose Data to the client,
I suspect that you must not allow another client to unlock a record that
the original client locked.

Is it now clearer that both your answers were unclear?

George:
To restate my point in brief: if you adhere to the locking protocol of the Data class on the server-side and if you don't expose the lock and unlock methods to the client-side, but instead provide business methods (which themselves adhere to the locking protocol), then the client-side need not be aware of the locking protocol.

I agree 100% with you now. So yes, the earth is round.
Regards,
Phil.

[Mogens Nidding]

WOW! Thanks for all your answers.
Regarding my question whether doing sanity checks will affect scoring, I am mostly reading a "yes" here... A "Yes" from Phil and Javini, I think, and a "Probably not" from George (?).
On one hand, George has a good point about not solving problems that aren't in the assignment. On the other hand, my assignment does have the statement pointed out by Javini: ("Locks a record so that it can only be updated or deleted by this client."). The fact that my DBMain interface is cookie free does not prevent sanity checks, so I still have to choose. Back on the first hand, none of the other DBMain documentation is good enough to merit a to-the-letter interpretation.
George, did you have locking cookies? The presence of locking cookies in the interface would necessitate sanity checks, I figure.
George, I agree with you that the GUI needn't worry about the locking protocol if the server does not expose locking. It does in my design, though, so that the GUI can have the server lock a record while the user edits or books it.

[George Marinkovich]

Hi Nicky,

Originally posted by Nicky Bodentien:
George, did you have locking cookies? The presence of locking cookies in the interface would necessitate sanity checks, I figure.

My Sun interface:

package suncertify.db;
public interface DBMain {
// Reads a record from the file. Returns an array where each
// element is a record value.
public String [] read(int recNo) throws RecordNotFoundException;
// Modifies the fields of a record. The new value for field n 
// appears in data[n].
public void update(int recNo, String [] data)
throws RecordNotFoundException;
// Deletes a record, making the record number and associated disk
// storage available for reuse. 
public void delete(int recNo) throws RecordNotFoundException;
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. A null value in criteria[n] matches any field
// value. A non-null  value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)
public int [] find(String [] criteria)
throws RecordNotFoundException;
// Creates a new record in the database (possibly reusing a
// deleted entry). Inserts the given data, and returns the record
// number of the new record.
public int create(String [] data) throws DuplicateKeyException;
// Locks a record so that it can only be updated or deleted by this client.
// If the specified record is already locked, the current thread gives up
// the CPU and consumes no CPU cycles until the record is unlocked.
public void lock(int recNo) throws RecordNotFoundException;
// Releases the lock on a record. 
public void unlock(int recNo) throws RecordNotFoundException;
// Determines if a record is currenly locked. Returns true if the
// record is locked, false otherwise.
public boolean isLocked(int recNo)
throws RecordNotFoundException;

So as you can see, I didn't have lock cookie. I don't like the way I implemented the lock and unlock methods anymore since I think I failed to satisfy the "Locks a record so that it can only be updated or deleted by this client" requirement. My locking protocol if followed will guarantee that this requirement will be satisfied, but only if the locking protocol is followed. I now believe the lock method needs to identify the client and store this information along with the record number in the lock variable. Ken Krebs gives a very good description of this in in his design summary. I refer you to the locking section.

George, I agree with you that the GUI needn't worry about the locking protocol if the server does not expose locking. It does in my design, though, so that the GUI can have the server lock a record while the user edits or books it.

My design exposed locking to the client and I did so for the same reason you state. I think the server should be able to lock a record while the user edits or books it, but this is a minority opinion on this forum. From my reading I think most people are using an optomistic booking strategy, that is, when a client books a record the client must type in the customer ID before the lock is acquired. I prefer the pessimistic booking strategy that we are using. In other words, until a lock has been acquired it's not a good idea to make the user type in the customer ID. I think the pessimistic booking strategy also handles the issue of booking an already booked record in an elegant manner.