Thanks. I will take that into account.
--
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send
On 2019/05/22 11:21 AM, Silvio wrote:
To determine our options I would like to raise my earlier question again: is there a binary difference in
MVStore/PageStore formats between version 199 and 196? In other words: would it be safe to revert to 196 without doing
dump/recreate cycles for all
Yesterday evening at about 20:00 another database on one of our servers got
corrupted (at least that is when errors started appearing in the logging).
There was limited server load at the time. In this case it was a database
of about 850Mb.
To determine our options I would like to raise my
Thank you, that is an excellent suggestion. The times are very short now
but there is no pressing reason for that other than hoping it would reduce
resource consumption. I will change that ASAP.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
Additionally, large write queues are very common in our system. At least
one of the most recent corruptions occurred when a user performed an action
that caused a new table to be created and ~200K records to be inserted into
it (using separate connect/insert/disconnect cycles, pooled of
On 2019/05/21 4:21 PM, Silvio wrote:
The database URLs currently look like:
None of that sounds problematic. You might be able to work around this issue simply by telling your pool to keep
connections alive for longer, which will reduce the number of startup/shutdown cycles each database
The database URLs currently look like:
jdbc:h2:/path/to/file;IGNORECASE=TRUE;MVCC=TRUE;LOCK_TIMEOUT=1
I have experimented with different FILE_LOCK settings but since the
databases are accessed from one single process this is unlikely to have any
influence. I could probably do without
What does one of your database URLs look like?
Are you perhaps call Thread.interrupt somewhere?
If so, that would close the database abruptly and force it to be re-opened on
the next connection attempt.
Doing that enough times is likely to cause corruption, because all kinds of stuff could be
