SCEA Part I, SCAJ, SCPJ, SCDJ, SCWCD, SCBCD, SCMAD<br /> <br />"The significant problems we face can not be solved at the same level of thinking we were at when we created them." - Albert Einstein
"I'm not back." - Bill Harding, Twister
SCEA Part I, SCAJ, SCPJ, SCDJ, SCWCD, SCBCD, SCMAD<br /> <br />"The significant problems we face can not be solved at the same level of thinking we were at when we created them." - Albert Einstein
Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.
I used synchronized blocks in my projeject and it is making a good job. But I never call wait() or notifyAll() methods. If the user attemps to lock a record locked an exception is thrown. I treated this exception and the user sees a warning message in a dialog box.
Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Correct me if I am wrong (and probably I am).
I am glad you replied and you hit the correct point whcih I was thinking.
I need your opinion.
I am almost done with my assignment(coding part, this is what I think).
I have implemented locking mechanism same like most of other folks ( waiting on Vector and again notifying).
Yesterday I re- read instructions and thought I am wrong ( I am ).
(...) (waiting on Vector and again notifying) (...) ( I love vector, so please no Array[]).
Record Object with instance variable recNo and cookie.
I will store it into vector and instead of waiting on Vector I will put thread waiting on Vector(i).wait() (where i is Record object).
Again notifying same thing Vector(i).notify and remove that Record object from vector.
"I'm not back." - Bill Harding, Twister
Philippe: you're not the only one here doing record-level locking.
Thinking back, it was that "consume no cycles" line that made me favor sync on the record in the first place;
Because practically speaking, there's little difference between "consume no cycles" and "consume very few cycles".
So I agree that it's extremely unlikely that this particular requirement is enforced rigidly
but those of us who do follow it should draw attention to it in choices.txt, as it helps mitigate possible whini...errr, criticism about "overly complex" sync mechanisms. After all, we're just following the spec.
"I'm not back." - Bill Harding, Twister
I have not the weight you and Andrew may have
You're saying we're fat?
Re. "Phil" - yeah, I only hesitated to use "Phil" because I knew it was an appropriate nickname in America, but I wasn't sure about Belgium. Though now I see you do sign "Phil" reasonably often, so I suppose I should have noted that previously. Thanks for confirming.
The down side is, if the only thing you're using the ArrayList for is info about locked records, then the ArrayList is probably much bigger than it needs to be.
you need to have an ArrayList size of 10000 rather than 10. Which seems inefficient.
However, some of us are using a full caching solution. I've got the complete data from all records in memory anyway, in an ArrayList. It really doesn't take that much memory, for the speed benefits I receive. (And if you have so many records that the memory is a problem, then I guarantee a non-cached solution will be really slow whenever find() is called.) So, once you've made the commitment to having one Record object in memory for every single record, locked or no, then it's pretty easy to put locking info in that same Record structure. And so now you've got a solution which uses an ArrayList and get() to access locking info, and is faster than HashMap. It just happens to take more memory.
So, I would way - if you're doing IO for every record access, no cacheing, then a HashMap is the ideal structure for managing locking info. If you're doing full caching, ArrayList is the way to go. IMO, anyway.
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
I have not the weight you and Andrew may have on this forum and it would be a pity that Manoj would lose points in locking just because of my lack of personal conviction power ...
"I'm not back." - Bill Harding, Twister