Steve Taiwan<br />SCJP 1.2, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, OCP 8i DBA, SCEA
James<br />SCJP 1.4 - 92%<br />SCJD - 93%<br />SCWCD 1.4 - 95%<br />SCBCD 1.3 - 100%<br />SCEA - 92%
James<br />SCJP 1.4 - 92%<br />SCJD - 93%<br />SCWCD 1.4 - 95%<br />SCBCD 1.3 - 100%<br />SCEA - 92%
Originally posted by Anton Golovin:
This thread should be very useful to current test-takers: we have located the common mistake about the locking mechanism. It is in the lock method and comes after the record to lock comes unlocked and is available for locking. Then, before locking, one should check if the record still exists, as the previous thread might have deleted it. Hope this helps people who have not turned their assignment in, and also those who failed but could pass with their locking getting more points.
SCJP 1.4, SCJD
Anton Golovin ([email protected]) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Originally posted by Paul Goh:
If you could kindly point me to a link where I could read up on the policies, I would really appreciate it as I do not want to make similar mistakes again.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
--------<br />Andy Zhu<br />scjp 1.4<br />scjd 1.4<br />SAS Certified Programmer 9.0
--------<br />Andy Zhu<br />scjp 1.4<br />scjd 1.4<br />SAS Certified Programmer 9.0
Originally posted by Anton Golovin:
1) Check that the record exists. If not, RecordNotFoundException.
2) while (record is locked by someone else AND (|) the record is not deleted) loop waiting
3) Once the loop exits, it could be the record is unlocked or it has been deleted. So, check for record not being deleted. If it is deleted, throw RecordNotFoundException. Otherwise, lock it.
In 2) this would prevent your method waiting needlessly on a locked record that is deleted. Ordinarily, if another thread deleted it, yours cuts in, checks it is locked, and continues waiting when it should not. With this code, it stops waiting a little bit sooner.
SCJP 1.4, SCJD
Originally posted by mike acre:
You must lock the record as the very first thing you do in lock().
Otherwise someone else may grab the lock and change the record.
It does not matter if the record is valid or not
Any other approach will be over synchronised.
Originally posted by Paul Goh:
Hi Andy,
The check flag of 0x8000 is a flag for deleted records, required by the assignment. I found out that when I use writeShort(0x8000) on the RAF, I have to use readUnsignedShort() to get back the correct value. I didn't analyze this issue any further to see why this is the case, because it works, and it is good enough for me...![]()
Originally posted by Marlene Miller:
Hi Paul,
Here is something I noticed in your lock method. It�s about a case where an invalid record number is passed.
I assume a valid recNo >= 1, since you subtract 1. I also assume recordOffset is the length of a record including the delete field.
If recNo == 0, at (1) fileOffset is firstRecordOffset � recordOffset.
Therefore fileOffset is probably > 0. An exception is not thrown.
If recNo == -1, at (1) fileOffset is firstRecordOffset � 2 * recordOffset
Therefore fileOffset is probably still > 0. An exception is not thrown.
By probably I mean, it is true if
the length of the metadata > record length (case recNo == 0) or
the length of the metadata > 2 * record length (case recNo == -1).
Marlene
[ October 05, 2004: Message edited by: Marlene Miller ]
Originally posted by mike acre:
You seem to be missing something fundamental.
You must lock the record as the very first thing you do in lock().
Otherwise someone else may grab the lock and change the record.
It does not matter if the record is valid or not, you only have a number or two in a Collection to represent the record, it does not matter if that record is invalid. What does matter is that the record is locked while you make your checks.
Any other approach will be over synchronised.
The code I have seen posted is unnecessarily complex.
Ignore me if you will, since I only got 44/80 for locking myself, but I am quite sure of this aspect, I have noted where I think I made an oversight.
--------<br />Andy Zhu<br />scjp 1.4<br />scjd 1.4<br />SAS Certified Programmer 9.0
Mike is right on this one, I don't even lock records, I simply lock numeric resources in my LockManager. My record locking code in the Data class works as follows
- lock resource, waiting until its available
- check if locked resource is a valid record
- unlock resource if not a valid record.
My delete code unlocks the resource when it deletes a record.
Originally posted by Nicky Bodentien:
what could possibly go wrong, and why should it be any better to swap the putLock and isValid calls?
[ October 06, 2004: Message edited by: Nicky Bodentien ]
[ October 06, 2004: Message edited by: Andrew Monkhouse ]
Originally posted by peter wooster:
Checking record validity within the synchronized lock method will involve nested synchronized blocks if you synchronize on the file when doing I/O. This can result in deadlock, if for example the delete code is synchronized on the file and tries to unlock the deleted record.
--------<br />Andy Zhu<br />scjp 1.4<br />scjd 1.4<br />SAS Certified Programmer 9.0
Actually I love the thin client approach as I don't have to worry about the security of the lock cookie, and also what will happen if the client accidentally disconnect halfway and I have to timeout and unlock the locked record.
Raj Nagappan<br />SCJP, SCJD, PhD
Originally posted by Anton Golovin:
I think the lock method is the reason for points taken off. It just must check for deleted record after it determines the record is unlocked (after the wait loop exits.) Otherwise, it could try to update a deleted record, and it would throw a RecordNotFoundException... So the easies way would be for the lock method to fail in the first place.
[ October 09, 2004: Message edited by: Anton Golovin ]
Raj Nagappan<br />SCJP, SCJD, PhD
SCJP 1.4<br />(WIP) SCJD B&S v2.3.3
There's a city wid manhunt for this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|