Hi,
I can't really say what the problem is. If the test works fine with
other VMs, then it sounds like a VM bug, but I'm not sure. I don't see
anything obvious
> H2 starts to write a HUGE amount of logs
> (in the data.trace file) ; it becomes very slow and the database is
> corrupted (we have to erase the files otherwise on next startup, H2
> complains the files are corrupted).
I would need to know what the very first exceptions are in the first
.trace.db file (please note the file is renamed to .old after a while
- I would need the very first exceptions in the first .trace.db file).
Also, I guess I would need some more information:
- What is your database URL?
- How many connections does your application use concurrently?
- Do you use temporary tables?
- Did you use LOG=0 or LOG=1?
- With which version of H2 was this database created?
You can find it out using:
select * from information_schema.settings where name='CREATE_BUILD'
or have a look in the SQL script created by the recover tool.
- Did the application run out of memory (once, or multiple times)?
- Do you use any settings or special features (for example cache settings,
two phase commit, linked tables)?
- Do you use any H2-specific system properties?
- Is the application multi-threaded?
- How did you start the Java process (java -Xmx... and so on)?
- Is it (or was it at some point) a networked file system?
- How big is the database (file sizes)?
- How much heap memory does the Java process have?
- Is it possible to reproduce this problem using a fresh database
(sometimes, or always)?
Regards,
Thomas
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
