In b) above, is it bad to use the common updateRecord method to get the data out there for my add? I liked it, because I only had to do the file manipulation in one place. But is it confusing to be doing an "update" within create functionality?
1. Depending upon how you set up your Data class the DuplicateKeyException
should never occur. Is this part of your interface or the interface
provided by Sun? If you have to check for it because its part of Sun's interface then you of course must do it, if you are throwing it by your
own design then I would re-think your design.
I am trying to prevent the locking problem where some other thread grabs this available record number after I find it, but before I lock it
and use it. In this situation, I am currently throwing a DuplicateKeyException. (I have seen the posts on this topic, and lots of folks don't feel this is necessary. However, I thought that it made sense in this particular situation.)
2. What do your directions say in regards to other threads waiting on a
record and then being notified when the record is available. I don't know
if your directions address this, but I know your code doesn't seem to address this.
Thread 1 attempting to add a new record at spot 33, Thread 2 beats Thread 1 to it and adds record 33. I would not want Thread 1 to wait forever for spot 33.
To summarize then,
1. Are you basically saying that as long as this record determination process is synchronized, I won't ever get in the crazy situation I am trying to prevent?
2. Likewise, is it true then that I really don't need any type of locking on the create?
3. Do you agree that the pseudo code above seems right? (The read record would probably never find a valid record out there and would process the create successfully. I would basically just be doing this check to meet the requirements of my spec for the DuplicateKeyException)
Yes you need locking!!! You need to lock your filehandler or you cache
(depends on how its designed.). When you create you use seek(), correct?
Well what happens if you seek to the correct position but then someone
else gets a hold of your filehandler and performs its own seek on the file.
No the position in the file is all screwed up. Remember, you can have the instances of filehandler you want, but there is only one file. And don't think I am telling you to lock the file. I am saying you need to synchronize on a variable that points to the file.
This variable is static in all cases from what I have seen.
Thanks for the tip on unlocking records - I don't have that in there yet. I assume that I also need to make sure only to update the cache list if the database file update succeeds. (i.e. update the file first and then continue on to the cache list update if it was successful. Otherwise, bail out and neither gets updated.)
1. Is the above what you do?
2. Do you use a WeakHashMap or just a HashMap when storing your locked records? (I still need to research this a little - I currently just have a HashMap.)