I am getting close to the end. Finishing and polishing a few things and soon will start to write documentation, etc.
If you don't mind I run this by you, here is the output of Roberto Perillo's Data Class Locking test run against my Data class.
I am able to run consistently up to 1000 iterations in Windows and Solaris 10, but I am just paranoid and I want to run this
by another set of eyes, just to make sure I am not missing anything. Here is the output for 1 iteration and for 10 iterations and I do appreciate
Do you reuse record numbers when creating records? Or just creating new ones at the end? Always good to know for evaluating such outputs (you didn't print the record number of the newly created record so I can't determine your approach)
I think something is not wrong, because I'm wondered with the following. Let's have a close look at thread 15:
line 242: 15 trying to lock record #1 on UpdatingRecord1Thread (line 242)
line 260: suncertify.db.RecordNotFoundException: Record Number: 1 not found in Data.lock() method.
after line 260 no records are created (or I must have missed them), so record 1 does not exist. So why an update and unlock are executed?
line 330: 15 trying to update record #1 on UpdatingRecord1Thread
line 331: 15 trying to unlock record #1 onUpdatingRecord1Thread
That's a bit weird. Do you have explanation for this behavior? I would expect that thread 15 throws a RNFE and no update and unlock are executed on record 1, because record does not exist.
In my create() method I do reuse records. First I iterate through my cache of records Map and I if I find a deleted record
that's where I place the new record.
If not I place the new record at the end.
In my lock() method first I do check the record exists. If it doesn't I throw a RecordNotFoundException.
Then on while the record is locked (locked Records Map contains my record) I wait.
Once the record is no longer locked (not present in the locked Records map)
I check again if the record exists and if it doesn't I throw a RecordNotFoundException.
If the record exists I generate the new cookie I put in in the Map for Locked Records
and return the cookie.
I see what you are saying. In line 330 Thread 15 should have thrown a RecordNotFoundException ... Strange.
I noticed Eclipse and NetBeans sometimes when I run the 100 and 1000 iterations run out of memory and behave strange.
I modified the DataClassTest to report the number of a created record and just in case after restarting Eclipse I run the 1 and 10 iterations test again.
The logic in your locking method seems ok to me, but I think you have still issues:
- line 284 indicates that record 1 does not exist anymore
- between this line and line 341-342-347-348 I don't see a record being created.
- 341-342 and 347-348 are still updating and unlocking record 1
If both IDEs run out of memory sometimes I'll think you have some kind of a memory issue (or maybe you allocate not enough memory). I only used Eclipse and didn't got any memory issues (even not when I ran the test class with 20000 iterations).
And as a final remark: it is not my job to analyze your output every time. I did it once to indicate what you have to look for. After you made your modifications you could have analyzed your output yourself (instead of just running tests and posting output again, think about ShowSomeEffort) and you would have noticed still the same issue as I mentioned before.
I do totally 100% get your point and I do appreciate your valuable feedback.
The output I posted was from Eclipse on Windows Java 6.
I did a test in NetBeans on Solaris 10/SPARC Java 6 as well and looked and reviewed carefully at the output and I didn't see the issue.
Also my bad I forgot to change the file name argument of my Database file from "C:\\db-1x3.db" to "/home/morillo/db-1x3.db" in the DataClassTest
last night when I was doing the testing and I guess I was all tired and braindead and that's why I was getting some errors in NetBeans.
I am developing for the most part in Windows/Eclipse but I test my server and network functionality running the Server on Solaris and client on Windows.
Definitely I will keep an eye on this doing some more tests and review them carefully just in case this weird behavior is not present.
It is definitely weird, because the logic of the lock method you described is exactly the same as mine (although I didn't generate a lockCookie because my lock method returns a void). So it certainly is an issue which should be monitored and investigated closely.