On Feb 10, 2005, at 7:45 AM, Brian McCallister wrote:
Quote of a Quote from Dan Debrunner
I'm not sure how hsqldb can be used as a test database, given that
multiple threads can overwrite each other, due to hsqldb only supporting
dirty read mode (no isolation). Thus if you see incorrect results it
seems you have to work out if hsqldb is the problem or your application.
Unit tests are usually single-threaded, so this isn't a problem. Having a better option (in-memory derby) would be even better though =)
Back when I was a consultant fixing transaction code was my bread an butter. Problem is people never test their code in a real world multithreaded scenario, so it blows up when they put it in production. Actually, a lot of time you can deadlock someone's code with a single thread if you change the isolation. This is due to j2ee servers, suspending and opening new transactions for a single thread. Container managed transaction flag REQUIRES_NEW and bean managed UserTransactions do this.
Anyway, you are right in that people almost never test multi-threaded, so maybe a dirty-mode will make people happy. It is one of those "would you rather be right or would you rather have people use your code" issues.
-dain
