File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Lock question! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Lock question!" Watch "Lock question!" New topic
Author

Lock question!

long lingyu
Ranch Hand

Joined: Feb 15, 2004
Posts: 51
My project is (B&S 2.2.2). It has requirement:

When I update a record ,I need a sequence like this: lock,update,unlock. Now , the updateRecord method has a parameter cookie,what's the meaning? I don't know the cookie if I do not invoke the lock method first.
Should I pass an arbitary value to the updateRecord method?
Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
Originally posted by long lingyu:
My project is (B&S 2.2.2). It has requirement:



When I update a record ,I need a sequence like this: lock,update,unlock. Now ,
the updateRecord method has a parameter cookie,what's the meaning? I don't know
the cookie if I do not invoke the lock method first.
Should I pass an arbitary value to the updateRecord method?

Hi,
In attempting to understand and resond to your question, I may state things
which you already know or have already implemented. Hopefully others will
provide helpful solutions to your questions.
The sequence: lock, update, unlock, is carried out by the client of your
software.
Here is the crux of the matter from the comments in the above code:
"Locks a record so that it can only be updated or deleted by this client."
That is, if ClientA locks record 100, then while this record is locked,
ClientB is not allowed to either lock the record or modify the contents of the
record.
What you call the "cookie" or the "lock cookie" I will call the clientId
(although it is always possible that you may come up with a design wherein
the cookie is not associated with a client, but associated with a business
method containing lock, update, unlock).
Let us assume that Data extends DBAccess (otherwise known as interface DBMain in
other assignments).
Let us further assume, which may or may not be true, depending on your design,
that each client using your system gets a unique Data instance on the server.
Now, once this is the case, it is easy for you to define an instance variable
which is part of this Data object which has a unique clientId (that is, there
are tons of bookish examples where objects are created and then assigned a
unique ID).
Since each client has a unique Data instance, and each Data has a unique
clientId, everything follows from there.
While I have not analyzed your method definitions--which are different from mine
in that mine do not have a cookie in their signatures--I suspect that the
basic underlying mechanism is quite similar.
Thanks,
Javini Javono
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Long,
Originally posted by long lingyu:

When I update a record ,I need a sequence like this: lock,update,unlock.

Agreed. That would look something like this, right?


Now , the updateRecord method has a parameter cookie,what's the meaning?

The cookie is the lockCookie returned by lockRecord.

I don't know the cookie if I do not invoke the lock method first.

Absolutely true.

Should I pass an arbitary value to the updateRecord method?

No, why be arbitrary when you can pass the actual lockCookie returned from lockRecord?


Regards, George
SCJP, SCJD, SCWCD, SCBCD
long lingyu
Ranch Hand

Joined: Feb 15, 2004
Posts: 51
Sorry,I haven't said very clearly. My meaning is that :Should I call the sequence in the client?
Jonathan Liu
Greenhorn

Joined: Aug 21, 2003
Posts: 26
Hi Long
I believe what George said is very clear, you should do this way:
long lockCookie = data.lockRecord(long recNo);
data.updateRecord(recNo, data, lockCookie);
data.unlock(recNo, lockCookie)
maybe you can tell what and how would you do if you don't call the sequence.
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Originally posted by long lingyu:
Sorry,I haven't said very clearly. My meaning is that :Should I call the sequence in the client?

I Am assuming you are asking about the sequence that is given by George. If so, then it depends on your design. If you want to allow the client to deal your locking mechanism, you can very well do that. If you don't want the client to know your locking strategy or whether locking exists or not you can simply make it transperent to client by doing all locking in Data or DataAdapter or other class in your business layer or data layer.
Good Luck.
long lingyu
Ranch Hand

Joined: Feb 15, 2004
Posts: 51
There is discussion about 2-tier and 3-tier. According your word, I can think that the two design are both right. Am I?
I use a HashMap in Data class to keep the record number, should the HashMap have static property?
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi Long
Originally posted by long lingyu:
There is discussion about 2-tier and 3-tier. According your word, I can think that the two design are both right. Am I?

If you are using client side locking, I think it comes under 2-tier design. If the client is not exposed to locking strategy, then the design might be either 2-tier or 3-tier. I maybe wrong on this

I use a HashMap in Data class to keep the record number, should the HashMap have static property?
I should say "yes" as in my design I made it static. I'm not sure whether this holds good for all others designs also. But I think in most of the designs it should be static.

Good Luck.
long lingyu
Ranch Hand

Joined: Feb 15, 2004
Posts: 51
Should I expose the lock and unlock to the client? If I expose,the design is little comlex than not exposing. I can't make a determine.
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi Long
Originally posted by long lingyu:
Should I expose the lock and unlock to the client?

As I said before, it totally depends on your design. You can do both and both are acceptable in the context of the exam.

If I expose,the design is little comlex than not exposing.
That's right. The design may be complex or same. To give an example, instead of calling lock/unlock somewhere in your adapter you can lock the record from the client if you expose them. This means that client knows that some locking mechanism is going on there. If you do not expose, then you should be calling the same sequence, but in some adapater to Data class or in Data class or in business layer.
But I did not expose to the client because I do not want the client to know how my locking is working and whether locking is there or not. Locking should be transparent to the client in my sense.
I can't make a determine.
You should make a decision. Here's what I know, most people will not expose locking to the client including me.

Good Luck.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Long,
Should I expose the lock and unlock to the client?

Mmh... that question rings me a bell ... but I cannot remember.
If I expose,the design is little comlex than not exposing. I can't make a determine.

Less complex to expose your whole data interface to the client, including locking?
Think of the fact that if you don't, your client has just 2 main business methods to call on the server: search(...) and book(...). Wouldn't your client be easier to code and maintain?
Regards,
Phil.
long lingyu
Ranch Hand

Joined: Feb 15, 2004
Posts: 51
Phil, I have read your post of the related topics. If I do not expose the lock/unlock, Are there any risk about passing the test?
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Long,
Phil, I have read your post of the related topics. If I do not expose the lock/unlock, Are there any risk about passing the test?

No risk at all. In the meantime, the published results show that both designs are equally accepted by SUN. If you justify your choice (and the thread you mention includes tons of arguments in favor of both designs ), you should be OK, whatever your personal choice.
Now be aware that the choice is not "exposing the lock/unlock methods to the client", but "exposing the data interface to the client".
Regards,
Phil.
long lingyu
Ranch Hand

Joined: Feb 15, 2004
Posts: 51
Phil, Should I expose all the method of the class Data? as Exposing interfacce DBAccess? There are only three method exposing for client in my design.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
2.5-tiers?
Or you expose the whole DBAccess interface (2-tiers) or nothing from it (3-tiers).
Regards,
Phil.
Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
Hi,
In the relatively recent past, it has been established that you are free to decide
whether or not
1. The client-side software calls the methods of the Sun supplied interface
"located" on the server
(this interface called DataAccess or DBMain, depending on the assignment).
2. The client-side software calls business methods localed on the server.
However, at least one very recent exam had one sentence in the assignment
which clearly suggested that the DataAccess interface methods be invoked
by the client-side software. I recommend a thorough reading and re-reading
of your assignment; you may find, then again you may not, that your assignment
requires that the client-side code invoke the interface methods from the server.
If your assignment gives you a choice, here are the two choices, and let's assume
RMI is being used:
1. Client --> BusinessMethods ---RMI---> Data ---> Database
2. Client ---RMI---> Business Methods ---> Data ---> Database
What is known about relatively recent exams and very recent exams is the
following: (a) the exam may be ambiguous as to which option (1 or 2) to
choose, or (b) the exam may contain one phrase which unambiguously
suggests that option 1 be chosen.
If you have a choice, I'd recommend option 1 for this assignment. Once you have
option 1 up and running and tested, you can, if you feel you must, refactor,
I would think with relatively little effort to move from option 1 to option 2.
I recommend option 1 for numerous reasons, but one reason is that you supply
the client-side software with a generic database which would work for any
database (whether it be a book purchasing system, a reservation system, and
so on).
Thanks,
Javini Javono
Gaz Smith
Greenhorn

Joined: Jan 25, 2004
Posts: 8
Javini,

However, at least one very recent exam had one sentence in the assignment
which clearly suggested that the DataAccess interface methods be invoked
by the client-side software.

Out of interest can you tell us what this sentence was?
long lingyu
Ranch Hand

Joined: Feb 15, 2004
Posts: 51
Javini,I have thought about the two option. From my opinion, option 2 may be easier than option 1. If the test result is independent on the option, I prefer to the option 2. Because from a system view, it is not the business layer to call the RMI. Connecting server is the duty of the client,then the server call business method and business method access the database. Maybe I am wong.
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hey Javini,
I am also curious to know. If you can remember that statement maybe you can tell us and clarify things. Maybe am too poor in english to understand that inner meaning
Thanks.
Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
Hi,
Topic: FBN: Which classes in which package?
http://www.coderanch.com/t/184982/java-developer-SCJD/certification/FBN-Which-classes-which-package

To connect with your server, you should create a client program. This
implementation should include a class that implements the same public methods as
the suncertify.db.Data class, although it will need different constructors to
allow it to support the network configuration.

Thanks,
Javini Javono
[ March 14, 2004: Message edited by: Javini Javono ]
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Thanks Javini. I re-checked mine and there is nothing like that
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Javini,
However, at least one very recent exam had one sentence in the assignment
which clearly suggested that the DataAccess interface methods be invoked
by the client-side software.


Topic: FBN: Which classes in which package?
http://www.coderanch.com/t/184982/java-developer-SCJD/certification/FBN-Which-classes-which-package
To connect with your server, you should create a client program. This
implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.

FBN is a (very) *old* assignment and not a "very recent" one .
You could read the SCJD FAQ. There is lots of useful information out there.
Regards,
Phil.
[ March 14, 2004: Message edited by: Philippe Maquet ]
Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
Hi,
Thanks, Phil. I assumed it was a very recent assignment because
it was a recent posting, and it different from other assignment
specifications.
Thanks
Javini Javono
Eric Kim
Ranch Hand

Joined: Feb 21, 2004
Posts: 37
For this interface:
public long lock(int recNo) throws RecordNotFoundException
When you do lock, hwo do you generate a value and return it? Can it be simply recNum?
Thanks
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi Eric
Originally posted by Eric Kim:
For this interface:
public long lock(int recNo) throws RecordNotFoundException
When you do lock, hwo do you generate a value and return it? Can it be simply recNum?
Thanks

You can return the record number itself and use it as a cookie if you are doing "record locking" in the data access design. Else I'm not sure if it works or not. Alternative options are to use a static variable of type long in your data access class and increment it for each client. Yet another approach is to use the system time as a cookie.
Basic concept of lock cookie is that it MUST be UNIQUE for each client. You can do it in any way, but it must be assured that its unique.
long lingyu
Ranch Hand

Joined: Feb 15, 2004
Posts: 51
How can I test the record which is already locked? Should I access the HashMap and compare the cookie?
Eric Kim
Ranch Hand

Joined: Feb 21, 2004
Posts: 37
For this interface:
public long lock(int recNo) throws RecordNotFoundException
When you do lock, hwo do you generate a value and return it? Can it be simply recNum?
Thanks
Eric Kim
Ranch Hand

Joined: Feb 21, 2004
Posts: 37
Sorry for generating the same post twice.
long lingyu
Ranch Hand

Joined: Feb 15, 2004
Posts: 51
You can generate the cookie using random or increment a long value simply.
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Eric,
Originally posted by Eric Kim:
Sorry for generating the same post twice.

If this happens, you can edit the duplicate post. One of the options while you're editing your post is deletion. This will get rid of your duplicate post.
Mellon Sun
Ranch Hand

Joined: Feb 20, 2003
Posts: 126
Originally posted by Eric Kim:
For this interface:
public long lock(int recNo) throws RecordNotFoundException
When you do lock, hwo do you generate a value and return it? Can it be simply recNum?
Thanks

If you return the recNo as the lockNum(cookie), which means two clients can get the same cookie if they modify the same record simultaneously. The lock will failed then. So I don't think you can return the recNo as the lockNum.


SCJP,SCWCD1.3,SCWCD1.4,SCJD,SCBCD5,SCEA5
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Satish,
You can return the record number itself and use it as a cookie if you are doing "record locking" in the data access design. Else I'm not sure if it works or not. Alternative options are to use a static variable of type long in your data access class and increment it for each client. Yet another approach is to use the system time as a cookie.
Basic concept of lock cookie is that it MUST be UNIQUE for each client. You can do it in any way, but it must be assured that its unique.

I am sorry about that, but I cannot agree with anything you wrote above:
- the recNo is not a good candidate to be a lock cookie (easy to guess)
- neither a long variable simply incremented;
- neither the system time (which can be not unique BTW)
- neither that the cookie "MUST be UNIQUE for each client".
Except in the unprobable case (because it's not the most efficient way of doing it) that you use cookies to uniquely identify clients, the only quality you should expect from a generated cookie is that it's difficult to guess. And Random.nextLong() is perfect to play that role.
Regards,
Phil.
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi Phil
Originally posted by Philippe Maquet:
Hi Satish,
I am sorry about that, but I cannot agree with anything you wrote above:
- the recNo is not a good candidate to be a lock cookie (easy to guess)

Well, obviously recNo its not a good candidate. But for the scope of the project, I think security is not a constraint and if we are lazy enough that we cannot come up with a new cookie generator, we can use recNo itself. This only works if the locking mechanism involved is "record level locking". Lastly, we have to document in bold that we are lazy and so we just re-used recNo like this

- neither a long variable simply incremented;

I do not see any particular reason why we should not use a static long variable and increment it to use as a cookie. Maybe you can enlighten me here.

- neither the system time (which can be not unique BTW)

Hi Eric, I was a little doubtful while suggesting this option. Sorry about that. That's right, it is not guareented to be unique. Thanks Phil.

- neither that the cookie "MUST be UNIQUE for each client".

What I mean by "MUST be UNIQUE for each client" is: As long as multiple clients are working on the db file at the same time i.e. simulataneusly accessing the records(like a client reading, another writing, another deleting..), then in that particular case I believe that each client MUST HAVE A UNIQUE COOKIE. To rephrase, at any particular point, the cookies that are hold by the clients MUST BE UNIQUE. Am I wrong, Phil?

Except in the unprobable case (because it's not the most efficient way of doing it) that you use cookies to uniquely identify clients, the only quality you should expect from a generated cookie is that it's difficult to guess. And Random.nextLong() is perfect to play that role.
Regards,
Phil.
I agree that Random.nextLong() is the best way BTW, I have just gone through the API for Random.nextLong(): All 2^64 possible long values are produced with (approximately) equal probability. This is also giving a unique value out of the 2^64 probable values right? Then why do you think that just incrementing the static long variable will not suffice as it also give a unique value. Is this the reason for generating a non-guessing number for security purposes?

Thanks.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Satish,
I agree that Random.nextLong() is the best way BTW, I have just gone through the API for Random.nextLong(): All 2^64 possible long values are produced with (approximately) equal probability. This is also giving a unique value out of the 2^64 probable values right? Then why do you think that just incrementing the static long variable will not suffice as it also give a unique value. Is this the reason for generating a non-guessing number for security purposes?

As you state yourself, Random.nextLong() doesn't garantee to return unique values (just a very very high probability that the values returned will be unique). But as they must not anyway... (back to this below).
The main quality of such a cookie is to be difficult to guess, and yes, that's why I like the Random class for that purpose.
Now using Random.nextLong() doesn't prevent you to make sure that you return unique cookies, but I think it would be overkill.
If your lockRecord has such a comment:
// Locks a record so that it can only be updated or deleted by this client.

you need to uniquely identify clients. But does it mean that you must do it with the help of the cookies generated? Is that the simplest way, especially if you allow a client to own multiple locks at a time? Cookies uniquely identify locks granted, not clients, and play the role of a sort of "password" in update() / delete() / unlock().
Now to be honest, if you don't expect the need of a unique client identifier (for automatic unlock of locks owned by crashed clients for instance, or even deadlock detection, areas where cookies cannot help you), it's probably better to generate unique cookies. But even in that case, I still think that Random.nextLong() gives enough "uniqueness" for the purpose.
Regards,
Phil.
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi Phil, if you do not mind to answer then I got a couple of dumb questions, you might say.
Originally posted by Philippe Maquet:
Hi Satish,
The main quality of such a cookie is to be difficult to guess, and yes, that's why I like the Random class for that purpose.

I do not understand why it must be difficult to guess. I will try to explain what I understood about this cookie. Please correct me if I'm wrong.
Consider the case where lock mechanism is not exposed to client and ONLY used in the adapter class that access the Data class.
Now in this case, where are we doing locking? In the adapter class, where we call the following sequence where locking is required: lock, update/delete, unlock. Now the reason for cookie is to identify each client(or I don't know, thread) who locked. Obviously we are the one's doing the whole locking thing here. What is the point in making it difficult to guess? I'm obvioulsy not understanding some very important concept behind making this cookie difficult to guess. If you can explain with any example, that would be really great of you. Also Andrew told the same thing sometime back. I could not see any requirement anywhere in the instructions also that should be made difficult to guess. Then again, our instructions are left out ambiguosly intentionally so that we can make our design decisions and document them.

If your lockRecord has such a comment:

you need to uniquely identify clients. But does it mean that you must do it with the help of the cookies generated? Is that the simplest way, especially if you allow a client to own multiple locks at a time?

Phil, I do not understand why a client need to get multiple locks. See, what I am doing is to lock the record only for operations update and delete and unlock. Obviously update and delete are constrained to only one record in the file at a time. Then can you please tell me what might be the case where client needs multiple locks?

Cookies uniquely identify locks granted, not clients, and play the role of a sort of "password" in update() / delete() / unlock().

As you said "cookies uniquely identiry locks granted". locks granted to whom? Each thread? If so does'nt each thread identifies each server request and so each remote client? And also you say that it plays the role of sort of password, practically does passwords and ID uniquely identify a person or a work like that?

Regards,
Phil.

Appreciate it. Thanks.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Satish,
I do not understand why it must be difficult to guess. I will try to explain what I understood about this cookie. Please correct me if I'm wrong.
Consider the case where lock mechanism is not exposed to client and ONLY used in the adapter class that access the Data class.
Now in this case, where are we doing locking? In the adapter class, where we call the following sequence where locking is required: lock, update/delete, unlock. Now the reason for cookie is to identify each client(or I don't know, thread) who locked. Obviously we are the one's doing the whole locking thing here.

First, I think we are a bit unlucky to have received a version of the instructions with cookies!
Other instructions also have a comment like "Locks a record so that it can only be updated or deleted by this client.", so they don't need to ask themselves whether a lock cookie uniquely identifies a client...
The issue relates to what I put in bold in quoting you: the way cookies are generated concerns DBAccess *implementation* (Data internals). And you know the context within which *you* will use Data. But who knows if another programmer, in another application, will not reuse your DBAcess/Data it in a different context?
Phil, I do not understand why a client need to get multiple locks. See, what I am doing is to lock the record only for operations update and delete and unlock. Obviously update and delete are constrained to only one record in the file at a time. Then can you please tell me what might be the case where client needs multiple locks?

A client of Data (server-side or client-side, it doesn't change anything) would need multiple locks in the case (just an example) multiple bookings could be done in one transaction. I know that our business needs are other, but should Data be refactored just because a business need evolves? And what about the same other programmer as above, who has other business logic constraints?
As you said "cookies uniquely identiry locks granted". locks granted to whom? Each thread? If so does'nt each thread identifies each server request and so each remote client? And also you say that it plays the role of sort of password, practically does passwords and ID uniquely identify a person or a work like that?

OK, Satish I was unclear. And even wrong with the first part of the sentence (if the cookies are not garanteed to be unique, by definition they cannot uniquely identify anything ). But I think that the comparison with passwords is more valid. Passwords are not unique, just (ideally) difficult to guess.
I think the question you could ask to yourself is: "How would I identify Data clients uniquely if I had a version of the instructions with no cookie?". If you find an answer to that question, you won't use cookies for that purpose anymore. And you'll probably throw away the limitation you put on your locking scheme (one lock / client at a time).
Now Satish, what I write is just what *I* believe to be right. Remember that many people loose many points with Locking (the typical 44/80 scores), and that we still don't know why for sure (or I missed something).
Regards,
Phil.
[ March 17, 2004: Message edited by: Philippe Maquet ]
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Thanks Phil for the response. I read it twice. Could understand some and could'nt some. Thought of replying, but high time to sleep. So, just a note for now. Thanks alot. And am sorry for asking you so many questions as you can see they might be pretty much dumb for an experienced person like you. But as I donot have much(frankly none) experience, I could'nt understand many things at a time. Thanks to guys like you who always try to make things very clear.
Appreacite it very much. Thanks.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Satish,
Thanks Phil for the response. I read it twice. Could understand some and could'nt some. Thought of replying, but high time to sleep. So, just a note for now. Thanks alot. And am sorry for asking you so many questions as you can see they might be pretty much dumb for an experienced person like you. But as I donot have much(frankly none) experience, I could'nt understand many things at a time. Thanks to guys like you who always try to make things very clear.

  • Your questions are not dumb at all!
  • You're welcome
  • Sleep well!


  • Best regards,
    Phil.
    [ March 17, 2004: Message edited by: Philippe Maquet ]
    Satish Avadhanam
    Ranch Hand

    Joined: Aug 12, 2003
    Posts: 697
    Hey Phil, thanks. I think I understood it now. Thanks for your clear explanation of why cookies is not the which identify client uniquely.
    I got a couple of questions. Right now,
    1. Am not dealing with dead locks.
    2. Am not dealing with crashed clients.
    I want to document it accordingly like that. But what should be the tone in the documentation?
    1. Should I say that they did'nt ask(I mean project did'nt require them).
    2. Or I did'nt do(I was lazy ).
    Also there are other issues which I did'nt took care of and want to document them. Will ask them while documenting.
    Hey I think you did'nt submit yet right, so probably you cannot tell then ... just kidding. Please let me know what you think.
    Thanks.
    George Marinkovich
    Ranch Hand

    Joined: Apr 15, 2003
    Posts: 619
    Hi Satish,
    Originally posted by Satish Avadhanam:

    1. Am not dealing with dead locks.

    If you're really not dealing with deadlocks then definitely don't mention this in the design choices document. Maybe the examiner won't notice, you certainly don't want to bring it to his attention.
    To quote the from the assignment instructions:

    1) A data access system that provides record locking and a flexible search mechanism.
    2) Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.

    3) Locking (80 points)

    Seriously, I think a locking functionality that permits deadlock is inherently a seriously flawed implementation and you can expect to lose points if your implementation allows this to happen.
    What is it in your application design that you think might lead to a deadlock situation? You should also test your application extensively with a multi-threaded test harness. This sort of testing is no guarantee of finding deadlock, but at a minimum your design should be able to withstand this sort of testing.
    To advertise the fact that you have concerns that your implementation may permit deadlock to occur, is tantamount to asking for a deduction in the number of points awarded for locking.

    2. Am not dealing with crashed clients.

    I think you have a better rationale for not providing this capability. It's certainly not a bad thing to provide this capability but I think you can successfully argue that it's beyond the scope of the project.

    I want to document it accordingly like that. But what should be the tone in the documentation?
    1. Should I say that they did'nt ask(I mean project did'nt require them).
    2. Or I did'nt do(I was lazy ).

    I think the tone you want to set is that you were aware of the potential problem and its consequences but that in your judgment providing the capability was beyond the scope of the project's requirements. For example, I didn't support lock recovery in the case of crashed clients. Here's a paraphrase of what I said in my design choices document:
    "In network mode if the client application were to die for whatever reason
    after the client had obtained a lock and before it was able to call unlock,
    then that record would remain locked until the server was shutdown and
    restarted. The code does not currently handle this sort of client death
    situation. This should be handled in the final production system, but I
    decided not to implement it now since I believe it is out of the scope of
    the assignment."
     
     
    subject: Lock question!