Why did you decide to synchronize read and find
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.
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
What if the record was deleted after it has been displayed by the client but before the client tries to book the record.
Why not just use a get(record No) to get each record. Loop around from recordNo 0 to recordNo mapName.size().
Originally posted by Jim Yingst:
[Tony]: If you use File Channels do you have to lock the database at all ?
If you're doing one of the new-format (NX) assignments you probably have to implement a particular API which includes lock() and unlock() methods, and requires that update() and delete() throw a SecurityException if called on an unlocked record. Thus locking is required, regardless of whether you use FileChannel, RAF, or something else.
[Max]: 3. The real advantage of FileChannels (here)are guaranteed atomic actions, Interruptible IO, and better performance.
Eh, I still think you overstate the "guaranteed atomic" part, IMO. See my comments at the end of this thread. But interruptibility and performance are still excellent reasons to learn NIO.
Originally posted by Vlad Rabkin:
first, you don't know the sequence of record IDs:
1 is active
2 is deleted
3 is active
record 2 is not in HashMap, because it is deleted.
So you can't just loop continiously from 1 to size
Imagine following: HashMap size was 30.
you started to loop over. In the meanwhile somebody deleted 2 records. By reaching your 29 element you will get "IndexOutOfBoundsException",
which is RuntimeException.
All of this are drawbacks of cashing the Database...
The way this generally works is this. Your thread, say Thread #1, makes a local copy of the map(for efficiency), and does it's work there(this is Thread Memory, vs. Main Memory).
makes a local copy of the map
This depends on your implementation choices: There's no reason to remove deleted records: just mark then deleted. That is, have a isDeleted method on your Record object.
Imagine your hashMap size currently is about 100 MB (which is Ok: it is about 700,000 records).
100 Clients want to search. Your have to make a local copy (clone your HashMap) for every client thread.
Upssss: U suddenly need 100MBx100, which is fast 10GB!!!
Could you please confirm my assumption:
FileChannel: write block all other operation on the object, it means that reads will also automatically wait till write finishes.
Is it correct?