What happens if one thread reads an old cookie value, rather than the latest value suppied by another thread, because no synchronization was performed while reading?
What happens if another thread manages to execute resize() (see source for HashMap) while you're trying to get() an "unchanging" value?
If multiple threads access this map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally.
[Andrew]: nor the use of the lock manager in verifying the record number in update or delete.
[Jim]: Ummmm... I'm not sure what this means. When we verify a reord number for update or delete, we do have to look up the cookie in the HashMap, don't we? Are you saying that lookup need not be synchronized?
If all the access methods (Data Class) to a shared resource (LockManager) are synchronized then we need not synchronize the methods inside the LockManager.
Mmmm, I'd be interested in seeing just what Max said
[Max]: 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).
[Vlad]: The problem is if your database contains many records it will KILL the server:
I think you might enjoy reading a bit more about this.
he might have been suggesting that if you make a copy of the Map
You may even get a sort of partial copying
"Note that fail-fast behavior cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification."
To find(), I just loop through the ArrayList, synchonizing each individual access to the List; then after I've retrieved an individual record (and am no longer synced on the List) I sync on that record while I look at it. So there's no need for one long sync of the list; just lots of little ones. If multiple threads are doing this simultaneously, it's no problem.
Andrew have [allowed dirty reads] and have not lost a point for locking!
[Vlad] Have done something like this or you synhronized write/add/create methods also on HashSet and didn't synchronize read/find at all allowing dirty-reads like Max suggests?
[Andrew]Yes, I allowed dirty reads
[Andrew] Anyway, I did not incorporate read-locks into my design. But at the same time, the situation you were describing where a read could occur half way through a write causing garbled data could not occur in FBNS, since the provided methods getRecord() and modify() were both synchronized.
It seems that I have said something, what irritated you.
I was trying to differentiate between read locks, and synchronizing methods in the class (which prevents garbled data - what you are calling dirty reads). My definition of dirty reads is slightly different - my meaning is returning any dated data (or data which is known to be about to change) constitutes a dirty read. This was the definition I got from working with databases, where reading data prior to commit / rollback could result in a "dirty read" but not in reading garbled data.