This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Data.java puzzled me. My Data class extends java.io.RandomAccessFile and is not singleton pattern. All methods marked synchronized on static variable. Every record has a Read-Lock and Update-Lock. If a record is locked on its Update-Lock, no one can read and update it, and if it is locked on its Read-Lock, other threads can read but not update it. I use the lockCookie as the Update-Lock. In order to implement, I have a complex synchronized mechanism by using two java.util.concurrent.ConcurrentHashMap to store the locks for every record.
Is it necessary to be so complex?
Do I comprehend the instructions.html and the interface (DBAccess) wrongly?
Xin Gang Sun
boolean scjp_6 = true;
boolean scjd_URLyBird = willBeTrue();
Your Data class extends java.io.RandomAccessFile? Or just use it? About your approach, it looks like you are using the read-writelock design pattern with those read-lock/update-lock flags. Honestly, your current approach is a bit complex IMO. Do you really need 2 ConcurrentHashMaps?
When I first did my locking mechanism, I also tried using the read/write lock design pattern and sort of come across what you are expecting - some where there are records waiting meaning deadlock. The contention is really comes from when to set those flags on/off. However, this design pattern is indeed easy to understand yet quite hard to get it perfect.
Then I created my own class for locking using some singleton collection (ie only one record can be present in the collection) to control what record is currently locked. Now thinking back on this, I could have simplified this approach a bit more from what I have done.
Thank you, K. Tsang.
My Data extends java.io.RandomAccessFile and implements DBAccess. In my program, every thread has a Data instance to access data file.
You are right, it looks like the read/write lock design pattern. ConcurrentHashMap is necessary because it is atomic, it is important in my methods in order to ensure the locks thread-safe.
Now I have finished it, though it is hard to debug.
Hi Xin, if you are using RAF then why you need a separate class that extends RAF? Roel and I were saying more like:
About your RandomAccessDatabaseFile ... more of an interface from the code you provided.
Xin Gang Sun
Joined: Sep 03, 2009
Hi, K. Tsang.
Yes, but I think two designs are the same. My RADF class extends RAF and add readRecord() and writeRecord() method. In Data methods, readRecord()(a method in my RADF) instead of readXxx() can be more clear in my code. Actually, they are the same.