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
Originally posted by long lingyu:
Sorry,I haven't said very clearly. My meaning is that :Should I call the sequence in the client?
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.
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.
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.
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?
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.
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?
https://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.
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
Originally posted by Eric Kim:
Sorry for generating the same post twice.
Regards, George
SCJP, SCJD, SCWCD, SCBCD
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
SCJP,SCWCD1.3,SCWCD1.4,SCJD,SCBCD5,SCEA5
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.
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 wayBTW, 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?
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?
// Locks a record so that it can only be updated or deleted by this client.
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.
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.
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?
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?
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.
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."
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Gravity is a harsh mistress. But this tiny ad is pretty easy to deal with:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|