On 2014-09-29 10:17 AM, Viktor Voytovych wrote:
Hello, MULTI_THREADED=0 fixed the issue for me but it's not what I expected... What exactly MULTI_THREADED=1 does? Is there any good explanation posted? Does it really means that H2 is not multi threaded by default? Would all 32 CPU cores be used under heavy load?
By default we have a single big lock around the stuff that actually modifies the database. But the result-set processing is still multi-threaded in this mode. In MULTI_THREADED=1 mode, we attempt to use more fine-grained synchronization, but as you noticed, there are still problems there.
I've created a requested small test case (see attached H2MultiThreadedTester.java; required dependencies are h2database v.1.4.181 and commons-pool v.1.6). It runs great in case if MULTI_THREADED=0. For MULTI_THREADED=1 it throws different kinds of exceptions. Let me know if you have any questions regarding the test case.
Does it still crash if you remove the "LOG=0;UNDO_LOG=0" stuff? Because in general I don't care about debugging problems with those options because they're only intended for testing, not for production use.
-- Noel -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
