My current tests on the locking system always shows the same pattern, and I don't know if it's right or wrong: all updates, and deletes on the record 1 are done at the end of the test, except one or two. I've tested it and seen it on two different systems (one Windows, one Linux).
The problem is that I really don't know how to interpret this. Does anyone have the same pattern?
Here's my test method adapted from the one present in the FAQ:
Olivier Gregoire wrote:since these are threads, and the execution is non-predictable, even if we add randomness.
That's true of course, but it is strange that all these calls are at the end, but it could be completely valid behavior. Hard to say of course without any explanation (pseudo-code) how you make your Data class thread-safe. Are you already using lock/unlock methods?
The implementation that I chose for this is the basic Lock implementation. It is contained directly in my Data class. But now with the issue I'm facing, I'm thinking about the default implementation of the ReadWriteLock. I'll implement the other lock too and check if everything is ok.
Roughly, I perform the lock only in the test classes used in my JUnit.
It's simply using the DB api:
I don't really know how I can go deeper in the explanation regarding the lock system itself without copy/pasting the code. All I could say without revealing much is that my method pattern is the following:
If I already wrote too much, please tell me so I remove the code.
Your pseudo code snippets seem ok to me. Although I'm not a big fan of the return; statement in the unlock-method. I didn't use the fancy classes from the concurrent package, I just used synchronized (on each method), wait and notify. But I believe most people use a ReadWriteLock.