SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
SCJP(94%)
_ _ ________________________ _ _ <br /> <br />Just SCJP (but 93%)
SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
SCJP(94%)
SCJP(94%)
SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
Originally posted by Marcelo Camargo:
I think this exception is thrown by OS for its reasons (reasons we are not aware of), or for another thread that explicitilly calls that against a sleeping thread. And, in these situations, the thread that just waked-up don't need to re-check the while-expression and sleep again if the record its waiting is not available yet?
Another information is that I am using swallowing in many situations, all of that with an good explanation like that, in my code. Can't I use swallowing, even knowing what I am doing?
[/QB]
_ _ ________________________ _ _ <br /> <br />Just SCJP (but 93%)
SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
1. During this sequence: lock->delete record->unlock, if I check the db.isValidRecord() inside the call to locking.unlock(), as you mention, the record will not exist anymore, and an RNFE will be thrown. But its not true, because I need to unlock the record... How did you handle that?
2.About InterruptedException. I did not understand it yet. My implementation is swallowing this exception and checking again the while-expression, and if it was not reached, sleep again. Is this wrong? I need to interrupt the process and return some exception to the client?
SCJP(94%)
lock->delete record->unlock sequence
This is one issue I had to spend two cups of coffee to think about. I did not keep locking and persistance classes separated, therefore one could not lock or unlock a deleted record. Since deleting a record requires "owning" its lock, I decided unlocking is not required after deleting one record, for simplicity reasons.
SCJP(94%)
lock->delete record->unlock sequence
This is one issue I had to spend two cups of coffee to think about. I did not keep locking and persistance classes separated, therefore one could not lock or unlock a deleted record. Since deleting a record requires "owning" its lock, I decided unlocking is not required after deleting one record, for simplicity reasons.
SCJP(94%)
1. During this sequence: lock->delete record->unlock, if I check the db.isValidRecord() inside the call to locking.unlock(), as you mention, the record will not exist anymore, and an RNFE will be thrown. But its not true, because I need to unlock the record... How did you handle that?
SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
Originally posted by Joaquim Vasconcellos:
I took the same approach dealing with InterruptedException. I believe there is no reason to leave the while loop when this exception is raised. Although I don't know why this checked exception is raised, I don't think it is appropriate to rethrow it as a RNF exception (they have different meanings) and I strongly believe runtime exceptions shouldn't be used with RMI.
Originally posted by Joaquim Vasconcellos:
Why notifyAll? Why not notify? Only one thread will be able to acquire the lock thereafter, so waking them all up is unneeded (unless there is an issue about notify and notifyAll I'm unaware of)
_ _ ________________________ _ _ <br /> <br />Just SCJP (but 93%)
During this sequence: lock->delete record->unlock, if I check the db.isValidRecord() inside the call to locking.unlock(), as you mention, the record will not exist anymore, and an RNFE will be thrown. But its not true, because I need to unlock the record... How did you handle that?
_ _ ________________________ _ _ <br /> <br />Just SCJP (but 93%)
SCJP(94%)
SCJP(94%)
SCJP(94%)
DBAccess interface signature:
public long lockRecord(long recNo) throws RecordNotFoundException;
My implementation of this interface:
public long lockRecord(long recNo) throws IllegalArgumentException,
LockAttemptFailedException, RecordNotFoundException,
DatabaseFailureException {
long token = 0;
try {
token = logicalRecordLock.lockRecord(recNo);
} catch (IllegalArgumentException iae) {
/* re-throw the exception */
throw iae;
} catch (LockAttemptFailedException lafe) {
/* re-throw the exception */
throw lafe;
}
try {
filePersistence.readRecord(recNo);
} catch (IllegalArgumentException iae) {
/* unlock and re-throw the exception (not probable to be thrown) */
logicalRecordLock.unlock(recNo, token);
throw iae;
} catch (RecordNotFoundException rnfe) {
/* unlock and re-throw the exception */
logicalRecordLock.unlock(recNo, token);
throw rnfe;
} catch (DatabaseFailureException dbfe) {
/* unlock record and re-throw the exception */
logicalRecordLock.unlock(recNo, token);
throw dbfe;
}
/* The record is valid, then return the lock token */
return token;
}
Gabriel Vargas
SCJP, SCJD, now studying for SCWCD and working to be a better person
and the most important reason for me is the object locked is the record and not makes sense to unlock a thing than doesn't exists. (I see a deja vu about this point )
SCJP(94%)
and the most important reason for me is the object locked is the record and not makes sense to unlock a thing than doesn't exists. (I see a deja vu about this point )
SCJP(94%)
I first used notifyAll and then realized the same thing. I changed it to notify, and guess what: the code was much faster in the execution of a heavy multithreaded test, and still worked fine. Even though the LockManager class was a singleton. So apparantly the fear Marcelo is expressing just doesn't happen - or I must have been extremely lucky with testing...
SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
Don't you compare cookie/owner of the lock with the current thread?
within your try block, shouldn't you have a if clause:
if (record is locked){
unlock record;
}
SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
Marcelo, in your lock method you catch some exceptions and do nothing, i don't find any reason to do that. for the second try i would prefer use semantic defined for Lock class, i means, if finally you must unlock record i think is better to use a finally block and don't catch any exception because again you do nothing. I think it can look like this:
SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
I thing to clarify, Should we check isRecordLock() in the delete
method body of the Data class?
I am doing a check before deleting the record from database file.
then invoke lockManager's unlock method (no Data class's unlock )
SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
Gabriel Vargas
SCJP, SCJD, now studying for SCWCD and working to be a better person
No one can make you feel inferior without your consent - Eleanor Roosevelt. tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|