The following is adapted from Bob Perillo's original class which was used for Urlybird. Anyone utilisng this class will probably have to make some
adjustments, especially in the FindingRecordsThread() method. One area where your code may differ is that I did my unlocking in a finally block
and I also used a cache map to cut down on I/O. The loop can be increased to whatever you like and exceptions will be thrown dependant upon
input. The program should complete fairly quickly and if it sits there hanging this probably indicates deadlock.
And i guess your SecurityException is a checked exception... But how could this code compile in your test-case? Or maybe i'm missing something here but i would expect a try/catch around the call to unlock in the finally block
Joined: Jan 06, 2009
Sorry Roel not quite sure what you mean here? And my SecurityException class extends RuntimeException.
My lock/process/unlock method calls are delegated to my Data class. so my RemoteServicesImpl class calls the following on the Data singleton
delegated on SERVER mode startup
I don't call unlock() within say the Update() method. But yes the whole lock/process/unlock is within a try block.
Both these classes throw either a ServicesException/RemoteServicesException so when the Data instance is called this is also
wrapped in a try/catch block.
I was just wondering why your deadlock testing class compiles, but if your SecurityException extends RuntimeException (like you said), then that's the reason why. I thought that your SecurityException was a checked exception (like i did myself in my code, but with the RecordNotFoundException), so i was a bit amazed that your code did compile.