NX: IOException: Bad file descriptor

[Terry Martinson]

I'm getting an IOException for a bad file descriptor.

java.io.IOException: Bad file descriptor
at java.io.RandomAccessFile.writeBytes(Native Method)
at java.io.RandomAccessFile.write(RandomAccessFile.java:435)
at suncertify.db.Data.updateRecord(Data.java:214)

I am setting up multiple threads to pound the synchronization code with updates. I have a singleton Data instance, and my Data.update method is synchronized. My raf is opened in "rwd" mode.
I don't understand how I could be having a synchronization problem. And the only info I can find on file descriptors is the RandomAccessFile.getFD() method which returns a FileDescriptor. This FileDescriptor class has a synch method which I thought might be the answer to my problem, but calling it has no affect. I still get the error above.
1. Anyone have any information on the Bad file descriptor message? (I have searched this forum, google, etc. and not coming up with much.)
2. Anyone know whether this FileDescriptor synch method is needed when using the raf approach?
3. Other ideas on what my problem could be?
Thanks!
TJ

[Ken Krebs]

TJ<
Are you somehow using a reference to a RandomAccessFile that has previously been closed ?

[George Marinkovich]

Hi Terry,
You say your update method is synchronized, but that begs the question:
Are all the methods that move the file pointer synchronized?
For example, the read method doesn't change the contents of the database file but it sure moves the file pointer. Right?
Hope this helps,
George

[Terry Martinson]

Thanks for responding guys.
My raf doesn't get closed until the end, so I don't think that is the problem.
Here is my setup:
1. I have static synchronized Data.getInstance() method which gets my 1
instance (i.e. if null, generate the instance, else return the instance)?
**** this synchronization would be on the Class instance since static. Added this to prevent 2 threads from calling getInstance at the same time and inadvertently creating 2 instances of Data rather than my singleton.
2. My create, update, delete, read methods in Data are synchronized.
**** this synchronization would be on the Data instance, for the physical file locking
3. My logical record locking is very similar to Max, where I synchronize on
a lockedRooms HashMap in both lock and unlock.
I'm assuming I have a flaw somewhere, because RandomAccessFile should work fine if I get it set up right. Simply going to FileChannel is not going to fix this, right?
Is there any issue with kicking off a bunch of threads that all attempt to get the singleton Data instance and do stuff with it? For example, in my update multithread test, each thread will attempt the following:

  
String[] modifiedData =  {"something","something",etc., "something"};
long cookie = Data.getInstance().lockRecord(30);
Data.getInstance().updateRecord(30, mod30Data, cookie);
Data.getInstance().unlock(30, cookie);

At one point I actually grabbed the Data instance up front and sent it to each thread, but I was having a problem with that to and I thought it was because I was saving multiple pointers to the Data instance (i.e. one in each generated thread)
Any help appreciated!
TJ

[Ken Krebs]

My raf doesn't get closed until the end, so I don't think that is the problem.

until the end of what ???
Do you open and close the file every time you access (read or write) it ?
It sure sounds like the file pointer is getting whacked.
Have you tried opening up the whacked file with a hex editor/viewer to look for what might be going wrong ?

[Terry Martinson]

Ken - I THINK THAT IS IT!!! Thank you.
your quote from above:

until the end of what ???
Do you open and close the file every time you access (read or write) it ?
It sure sounds like the file pointer is getting whacked.

the end of what ------ the end of my test class execution!!!
I don't open/close every time. But when I reach the end of my test class that cranks off all the threads, I SHOULD NOT BE CLOSING THE RAF, AND I AM. All the threads are still out there expecting the raf to be open.
My test code is at home, so I'll have to wait and test it tonight! Once again, I have hope of someday finishing this assignment!!!
I SHOULD HAVE CAUGHT THIS!!! Thank you very much!
TJ