NX: Multithreaded Testing Problem

[Terry Martinson]

I have a strange thing happening when I attempt a multithreaded test and its driving me crazy.
I use the Data singleton approach. Here is my sample test class pseudo-code (I have the appropriate try/catches in my real code):
Test Class:

  
// this first read just a check to make sure I can get at data
String[] recordInfo = Data.getInstance().readRecord(24);
for (int i=0; i < recordInfo.length; i++) {
    System.out.println("field " + i + "=" + recordInfo[i]);
}
for (int i = 0; i < 3; i++) {
    MyLockThread t = new MyLockThread("LockThread_" + i);
    t.start();
}
// SECOND READ IS THIS - just an extra check
// if this is in here it works, but why?
String[] recordInfo = Data.getInstance().readRecord(24);
for (int i=0; i < recordInfo.length; i++) {
    System.out.println("field " + i + "=" + recordInfo[i]);
}

MyLockThread run method:

  
Long recNo = new Long(24);
long cookie = Data.getInstance().lockRecord(recNo.longValue());
Thread.currentThread().sleep((long)(Math.random()*1000)); 
Data.getInstance().unlock(recNo.longValue(), cookie);         

If I leave in the SECOND READ above in my test class, it works fine and the locks wait appropriately, etc.
If I remove the SECOND READ above, then all threads say they can't find the record so it never gets a lock.
There's something I'm just not seeing here. Ideas?
TJ

[Terry Martinson]

Getting a little farther on this one. Here is what is happening now. (And the second read shown above no longer fixes the problem.)
I'm getting this error:

java.io.IOException: Bad file descriptor
at java.io.RandomAccessFile.seek(Native Method)
at suncertify.db.Data.readRecord(Data.java:115)
at suncertify.db.Data.lockRecord(Data.java:442)

I have multiple threads out there, and each is grabbing a singleton Data instance and then calling the Data.lock method. My lock method has this:

  
    // lockedRooms is HashMap of cookies
    synchronized(lockedRooms){
             readRecord(recNo);

I would expect that only one thread would be getting into this synchronized block on lockedRooms at a time, so only one thread would be hitting the singleton Data instance at one time with the readRecord method. The Data.readRecord method is a synchronized method.
I realize that this is a nexted synchronization, but I followed Andrew's idea of documenting all the synchronization paths in nexted synchronization thread, and I couldn't find any potential deadlock situations.
Ideas on the "bad file descriptor"? All I have found so far on this is that it means something about the file system being inconsistent.
TJ

[George Marinkovich]

Hi Terry,
I don't think you have a deadlock problem. My first thought is that access to your RandomAccessFile is not properly synchronized. So even though your Data class is a singleton what mechanism prevents simultaneous access to the RandomAccessFile (raf)? For example, are the methods that access the raf synchronized, or alternatively, is the code that accesses the raf within a block that's synchronized on the raf?
Also, I guess I'm a little surprised at the following:

My lock method has this:

    // lockedRooms is HashMap of cookies
    synchronized(lockedRooms) {
        readRecord(recNo);

Is that really in your Data.lock method? If so, what is readRecord(recNo) doing in there. I don't understand?
Hope this helps,
George

[Terry Martinson]

George -
Thanks for responding. Any help is appreciated as this is driving my bonkers. The methods that access my raf are synchronized. (i.e. the read, update, create, etc.)
In this test, only the lock is being called, so I don't have any other methods that could be getting in the way here.
I do currently have the read being called from within my lock. This just seemed like an easy way for me to determine if the record still existed at this point, because my lock needs to throw RecordNotFoundException.
I do have a cache list that I could check instead, and I think I will try that now, just to stay away from the file. However, I need to figure out what is going on here because whatever it is could also cause problems in my update/create/delete methods when I do a big multithreaded test on them. (i.e. they would basically be hitting the file lots of times, just like my current lock method.)
TJ

[Terry Martinson]

As I expected, using the cache from within my lock fixed the problem for my multithreaded locking test.
However, as I also expected, I have the same problem from within my multithreaded update test.
I just don't see how I can be getting this with a synchronized update method, and only 1 single Data instance.
Ideas???
TJ

[Terry Martinson]

Now that I have a more specific problem, I continue this thread here
TJ