It was my mistake in describing. we do use the BACKUP command and then
since it produces a zip file, we create a new zip file and copy inputStream
to another outputStream to create a new zip file (with some configs related
to the DB) and then give that zip file to the customers to use as their
When our application starts it performs schema updates to the H2 database
as needed.
Before performing updates we "SET EXCLUSIVE 1" and make sure that no table
locks exists ( "SELECT COUNT(*) FROM information_schema.locks" ).
The following schema update statement hangs the application:
alter
Further testing shows that when 'SET EXCLUSIVE 1' is NOT executed first,
the statement runs normally.
On Tuesday, September 9, 2014 1:23:30 PM UTC-4, D. Aldenderfer wrote:
>
> When our application starts it performs schema updates to the H2 database
> as needed.
>
> Before performing updates we
Can you either
(a) attach a debugger
(b) use ctrl-break in a command window
(c) connect with VisualVM
and generate a set of stack traces and locks of the active threads
when it is locked up?
Either that or a reproducible standalone test case.
Thanks.
--
You received this message because you a
In our project we execute sql files using Runscript.execute method of H2,
during one such execution, there was large number of delete statement for a
particular table in one of the sql file, the java utility handling the
execution exited in during execution of that file. The utility ran
success
How exactly did the tool fail?
Did you get any error messages or stack traces?
--
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...@googlegro
Hi,
Was there any kind of exception / stack trace?
Regards,
Thomas
On Wednesday, September 10, 2014, Sanchand wrote:
> In our project we execute sql files using Runscript.execute method of H2,
> during one such execution, there was large number of delete statement for a
> particular table in
Hi,
Yes, I can reproduce this problem. Thanks a lot for reporting! It happens
because of the (partially) descending index. It will be fixed in the next
release. A workaround is to use version 1.3.x, or (with 1.4.x), don't use
descending indexes.
Regards,
Thomas
On Monday, September 8, 2014, Dam
