I am wondering about the 100% scoring locking strategy.
My own view on this problem is clear and simple * Methods that perform operations with I/O are synchronized * There is a HashMap "lockedRecords" with key=recNo and value=Lock in the file * Implementation of DBAccess is trying to acquire the lock on the record using this code
* Implementation of DBAccess is trying to release the lock with the following
* There is a thread that is searching for timed out locks and releasing them
* After acquiring lock the instance of acquired lock is synchronized and at the end of the synchronized block the lock is released
As far as I know this is not a good solution. Can someone tell me why?
[ November 13, 2007: Message edited by: Daniel Travin ] [ November 13, 2007: Message edited by: Daniel Travin ]
The iterators returned by all of this class's "collection view methods" are fail-fast: if the map is structurally modified at any time after the iterator is created, in any way except through the iterator's own remove or add methods, the iterator will throw a ConcurrentModificationException. Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.
Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.
Joined: Oct 19, 2007
Yes, I agree that HashMap is not good data structure for this kind of task.
My question was about what objects to synchronize and how to synchronize inside the implementation of DBAccess methods.
I have read through this forum and I see that some people get 80/80 marks for locking and some of them get 44/80. That 's why I am asking for what locking strategy is the best from the Sun testers point of view.
Alex Belisle Turcot
Joined: Apr 26, 2005
I use an HashMap to hold informations on records that are locked. Manipulations done on my HashMap object are inside a synchronized block.
I would think you should be very advanced into your lock / unlock strategy before you worry too much about 80 or 44.. It is still unclear the cause for that..
I've read it could be caused by the exception thrown. Or the application is being accessed by clients from multiple platforms. Or SUN is using special "mean bad ass sent by aliens" test case. Or thread are using CPU cycle. Or unnecessary use of Notify/notifyall from your lock method. Or update/delete not making sure the record is locked. Or record can be unlocked by any thread (not just the owner). Or...
I think there is a long period of thinking and designing before worrying about the 80 or 44 scoring issue.
Well at least, that's how it works for me
regards, Alex [ November 13, 2007: Message edited by: Alex Belisle Turcot ]
Alex Belisle Turcot
Joined: Apr 26, 2005
If you want to identify your client from your lock object (HashMap), then some unique information on your client should be your value in your HashMap. I think that is what most people are using...
As for synchronizing on all I/O methods, remember that read operation must be able to perform concurrently no matter which records they access.
You can then choose, when a write operation is performed, to lock and forbid other write operations on it and/(or-not) also read operation on it.
If you read posts the ranch, you'll see that most people choose to ignore (in their lock/unlock strategy) the possibility that a read operation occurs during a write on the same record.
I do that.. Read operations don't need a lock, it's free for all. I'm not so gentle with write operations and they need to get permission.
Regards, Alex [ November 13, 2007: Message edited by: Alex Belisle Turcot ]
I do that.. Read operations don't need a lock, it's free for all.
As long as your sure there is a memory barrier of course, just thought I better mention that in case any threading newbie's take it the wrong way. There are can be a lot of gotcha's round removing locks on reads, though it can be done ...
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5