Re: [h2] Exception when opening DB after forced shutdown (1.3.176)

2014-06-05 Thread too
Hi,
I tested with the 1.3.178 and I can confirm that it resolved problem. Tried 
twice with new jar and problem has not occurred, then tried back with 
1.3.176 and replicated it immediately. With damaged DB then tried the new 
jar and it recovered just fine. 

I consider this fixed now, thank you! Looking forward for next release and 
will use the new jar in the meantime

thanks
Tono

On Wednesday, June 4, 2014 8:52:08 PM UTC+2, Thomas Mueller wrote:

 Hi,

 The latest build is available at: 
 http://h2database.com/html/build.html#automated

  Can you point me in some direction as what to look for?

 If you don't create temporary tables, then most likely the problem is 
 large result sets, as in some cases this will implicitly create temporary 
 tables. I found out this week that this was not well tested so far. I found 
 a way to better test it, and found a number of issues. I had to fix and 
 partially re-write this area, so I believe this will be resolved in the 
 next release.

 Regards,
 Thomas



 On Tue, Jun 3, 2014 at 10:58 AM, too ton...@gmail.com javascript: 
 wrote:

 Hello,
 I can test the fix for you easily, all I need is h2 jar with fix. 

 Regarding the test I tried all I could think of. Our app is fairly large 
 (15MB jar of classes with lots of framework-ish stuff happening in the 
 background) so it is difficult to point out the scenario. Tried INFO 
 logging to re-execute the same set of queries but that has not replicated 
 the problem. I am also pretty sure we do not create any temporary tables 
 explicitly (also searched code-base for create memory table).

 Can you point me in some direction as what to look for? I mean what would 
 you expect to be happening to create the table? Does H2 create temp tables 
 implicitly? All we do to trigger the problem are select queries (based on 
 the info log I had).

 thanks
 Tono

 On Monday, June 2, 2014 6:04:03 PM UTC+2, Thomas Mueller wrote:

 Hi,

 I could analyze it now. The problem seems to be that creating a 
 temporary table is not committed, and then the temporary table is deleted 
 in another session. I have a fix / workaround for that, but so far no test 
 case. Please tell me if you have a reproducible test case.

 Regards,
 Thomas



 On Tuesday, May 27, 2014, too ton...@gmail.com wrote:

 Even though I can reproduce this with our app I fail to create separate 
 test case to reproduce the problem (i.e. to break the DB). What I can do 
 is 
 send you database that H2 fails to open. Perhaps it is not really bug 
 during close but not robust enough recovery during startup. Zipped DB has 
 10MB and I can share it for you privately if you think that can help

 thanks
 Tono

 On Thursday, May 22, 2014 5:47:11 PM UTC+2, too wrote:

 I have experimented with this a little and here are few notes

- lock file remains in place - this is consistent with shutdown 
hooks not being executed during JVM abort
- size of DB file remains intact during runtime but during process 
termination the size rises by approximately 50MB - which contradicts 
previous point and it seems there is something executed during abort 
- I can replicate problem with 100% success rate using our app but 
I fail to create test app to replicate the problem (still have a few 
 ideas 
to try)
- I can replicate the problem with older 1.3.x releases as well as 
with latest 1.4.x release (with MV_STORE=FALSE) 
- even though I do not think that there are transactions in 
progress at the time of termination it is possible there are open 
 cursors 
or something similar - read-related

 I can avoid this problem by running H2 in server mode but that is not 
 what I want. 

 Tono

 On Tuesday, May 20, 2014 3:16:03 PM UTC+2, too wrote:

 Hi,
 Sometimes when our application is shut down forcibly it is unable to 
 start again with exceptions below. It does not appear that transaction is 
 in progress at the time of shutdown but I can not be sure. I was unable to 
 create test case but our application reproduces this quite consistently 
 (it's very rare that it starts after being terminated). 
 I have attached debug trace file for failed start - not for the 
 shutdown. I tried INFO logging for shutdown (breaking the db) but nothing 
 seemed interesting there, just bunch of selects. Also no error is logged 
 during shutdown or startup.

 Environment details are

- H2 - 1.3.176
- Java Runtime - Java(TM) SE Runtime Environment (1.7.0_17-b02, 
32b) on Java HotSpot(TM) Client VM (23.7-b01, mixed mode)
- Operating System - Windows 7 (64b, Service Pack 1, version 6.1) 
- connection URL - jdbc:h2:./dbfile;IFEXISTS=TRUE


 NullPointerException - this is what usually happens

 org.h2.jdbc.JdbcSQLException: General error: java.lang.
 NullPointerException [5-176]
  at org.h2.message.DbException.getJdbcSQLException(DbException.java:344) 
 ~[h2.jar:1.3.176]
  at org.h2.message.DbException.get(DbException.java:167) 
 ~[h2.jar

Re: [h2] Exception when opening DB after forced shutdown (1.3.176)

2014-06-05 Thread too
I just noticed the version is 1.4.178, not 1.3.x.. I will need to wait for 
stable release then before I can use the jar

Also my jUnit tests failed with inability to create in-memory DB because of 
missing driver (for jdbc:h2:mem:). not sure whether I'd have to load driver 
class explicitly for 1.4 but I am falling back to 1.3.x so I will not be 
investigating that

thanks
Tono

On Thursday, June 5, 2014 10:41:45 AM UTC+2, too wrote:

 Hi,
 I tested with the 1.3.178 and I can confirm that it resolved problem. 
 Tried twice with new jar and problem has not occurred, then tried back with 
 1.3.176 and replicated it immediately. With damaged DB then tried the new 
 jar and it recovered just fine. 

 I consider this fixed now, thank you! Looking forward for next release and 
 will use the new jar in the meantime

 thanks
 Tono

 On Wednesday, June 4, 2014 8:52:08 PM UTC+2, Thomas Mueller wrote:

 Hi,

 The latest build is available at: 
 http://h2database.com/html/build.html#automated

  Can you point me in some direction as what to look for?

 If you don't create temporary tables, then most likely the problem is 
 large result sets, as in some cases this will implicitly create temporary 
 tables. I found out this week that this was not well tested so far. I found 
 a way to better test it, and found a number of issues. I had to fix and 
 partially re-write this area, so I believe this will be resolved in the 
 next release.

 Regards,
 Thomas



 On Tue, Jun 3, 2014 at 10:58 AM, too ton...@gmail.com wrote:

 Hello,
 I can test the fix for you easily, all I need is h2 jar with fix. 

 Regarding the test I tried all I could think of. Our app is fairly large 
 (15MB jar of classes with lots of framework-ish stuff happening in the 
 background) so it is difficult to point out the scenario. Tried INFO 
 logging to re-execute the same set of queries but that has not replicated 
 the problem. I am also pretty sure we do not create any temporary tables 
 explicitly (also searched code-base for create memory table).

 Can you point me in some direction as what to look for? I mean what 
 would you expect to be happening to create the table? Does H2 create temp 
 tables implicitly? All we do to trigger the problem are select queries 
 (based on the info log I had).

 thanks
 Tono

 On Monday, June 2, 2014 6:04:03 PM UTC+2, Thomas Mueller wrote:

 Hi,

 I could analyze it now. The problem seems to be that creating a 
 temporary table is not committed, and then the temporary table is deleted 
 in another session. I have a fix / workaround for that, but so far no test 
 case. Please tell me if you have a reproducible test case.

 Regards,
 Thomas



 On Tuesday, May 27, 2014, too ton...@gmail.com wrote:

 Even though I can reproduce this with our app I fail to create 
 separate test case to reproduce the problem (i.e. to break the DB). What 
 I 
 can do is send you database that H2 fails to open. Perhaps it is not 
 really 
 bug during close but not robust enough recovery during startup. Zipped DB 
 has 10MB and I can share it for you privately if you think that can help

 thanks
 Tono

 On Thursday, May 22, 2014 5:47:11 PM UTC+2, too wrote:

 I have experimented with this a little and here are few notes

- lock file remains in place - this is consistent with shutdown 
hooks not being executed during JVM abort
- size of DB file remains intact during runtime but during process 
termination the size rises by approximately 50MB - which contradicts 
previous point and it seems there is something executed during abort 
- I can replicate problem with 100% success rate using our app but 
I fail to create test app to replicate the problem (still have a few 
 ideas 
to try)
- I can replicate the problem with older 1.3.x releases as well as 
with latest 1.4.x release (with MV_STORE=FALSE) 
- even though I do not think that there are transactions in 
progress at the time of termination it is possible there are open 
 cursors 
or something similar - read-related

 I can avoid this problem by running H2 in server mode but that is not 
 what I want. 

 Tono

 On Tuesday, May 20, 2014 3:16:03 PM UTC+2, too wrote:

 Hi,
 Sometimes when our application is shut down forcibly it is unable to 
 start again with exceptions below. It does not appear that transaction is 
 in progress at the time of shutdown but I can not be sure. I was unable 
 to 
 create test case but our application reproduces this quite consistently 
 (it's very rare that it starts after being terminated). 
 I have attached debug trace file for failed start - not for the 
 shutdown. I tried INFO logging for shutdown (breaking the db) but nothing 
 seemed interesting there, just bunch of selects. Also no error is logged 
 during shutdown or startup.

 Environment details are

- H2 - 1.3.176
- Java Runtime - Java(TM) SE Runtime Environment 
(1.7.0_17-b02, 32b) on Java HotSpot(TM) Client VM (23.7-b01, mixed

Re: [h2] Exception when opening DB after forced shutdown (1.3.176)

2014-06-03 Thread too
Hello,
I can test the fix for you easily, all I need is h2 jar with fix. 

Regarding the test I tried all I could think of. Our app is fairly large 
(15MB jar of classes with lots of framework-ish stuff happening in the 
background) so it is difficult to point out the scenario. Tried INFO 
logging to re-execute the same set of queries but that has not replicated 
the problem. I am also pretty sure we do not create any temporary tables 
explicitly (also searched code-base for create memory table).

Can you point me in some direction as what to look for? I mean what would 
you expect to be happening to create the table? Does H2 create temp tables 
implicitly? All we do to trigger the problem are select queries (based on 
the info log I had).

thanks
Tono

On Monday, June 2, 2014 6:04:03 PM UTC+2, Thomas Mueller wrote:

 Hi,

 I could analyze it now. The problem seems to be that creating a temporary 
 table is not committed, and then the temporary table is deleted in another 
 session. I have a fix / workaround for that, but so far no test case. 
 Please tell me if you have a reproducible test case.

 Regards,
 Thomas



 On Tuesday, May 27, 2014, too ton...@gmail.com javascript: wrote:

 Even though I can reproduce this with our app I fail to create separate 
 test case to reproduce the problem (i.e. to break the DB). What I can do is 
 send you database that H2 fails to open. Perhaps it is not really bug 
 during close but not robust enough recovery during startup. Zipped DB has 
 10MB and I can share it for you privately if you think that can help

 thanks
 Tono

 On Thursday, May 22, 2014 5:47:11 PM UTC+2, too wrote:

 I have experimented with this a little and here are few notes

- lock file remains in place - this is consistent with shutdown hooks 
not being executed during JVM abort
- size of DB file remains intact during runtime but during process 
termination the size rises by approximately 50MB - which contradicts 
previous point and it seems there is something executed during abort 
- I can replicate problem with 100% success rate using our app but I 
fail to create test app to replicate the problem (still have a few ideas 
 to 
try)
- I can replicate the problem with older 1.3.x releases as well as 
with latest 1.4.x release (with MV_STORE=FALSE) 
- even though I do not think that there are transactions in progress 
at the time of termination it is possible there are open cursors or 
something similar - read-related

 I can avoid this problem by running H2 in server mode but that is not 
 what I want. 

 Tono

 On Tuesday, May 20, 2014 3:16:03 PM UTC+2, too wrote:

 Hi,
 Sometimes when our application is shut down forcibly it is unable to 
 start again with exceptions below. It does not appear that transaction is 
 in progress at the time of shutdown but I can not be sure. I was unable to 
 create test case but our application reproduces this quite consistently 
 (it's very rare that it starts after being terminated). 
 I have attached debug trace file for failed start - not for the shutdown. 
 I tried INFO logging for shutdown (breaking the db) but nothing seemed 
 interesting there, just bunch of selects. Also no error is logged during 
 shutdown or startup.

 Environment details are

- H2 - 1.3.176
- Java Runtime - Java(TM) SE Runtime Environment (1.7.0_17-b02, 
32b) on Java HotSpot(TM) Client VM (23.7-b01, mixed mode)
- Operating System - Windows 7 (64b, Service Pack 1, version 6.1) 
- connection URL - jdbc:h2:./dbfile;IFEXISTS=TRUE


 NullPointerException - this is what usually happens

 org.h2.jdbc.JdbcSQLException: General error: 
 java.lang.NullPointerException 
 [5-176]
  at org.h2.message.DbException.getJdbcSQLException(DbException.java:344) 
 ~[h2.jar:1.3.176]
  at org.h2.message.DbException.get(DbException.java:167) 
 ~[h2.jar:1.3.176]
 at org.h2.message.DbException.convert(DbException.java:294) 
 ~[h2.jar:1.3.176]
  at org.h2.engine.Database.openDatabase(Database.java:291) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Database.init(Database.java:254) ~[h2.jar:1.3.176]
  at org.h2.engine.Engine.openSession(Engine.java:57) ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.openSession(Engine.java:164) ~[h2.jar:1.3.176]
  at org.h2.engine.Engine.createSessionAndValidate(Engine.java:142) 
 ~[h2.jar:1.3.176]
  at org.h2.engine.Engine.createSession(Engine.java:125) ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.createSession(Engine.java:27) ~[h2.jar:1.3.176]

  -- 
 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 email to h2-database@googlegroups.com.
 Visit this group at http://groups.google.com/group/h2-database.
 For more options, visit https://groups.google.com/d/optout.



-- 
You received this message because you

[h2] Re: Query processing in H2 DB

2014-06-03 Thread too
Hi,
I am not sure whether I understand the question but here are few tips to 
analyse H2 
performance http://zvikico.typepad.com/problog/2008/04/h2-performance.html

Tono

On Tuesday, June 3, 2014 12:55:58 PM UTC+2, krismat...@gmail.com wrote:

 Hello,

 I have a question about the H2 Database. Where can I analyzing the code 
 about query processing and optimization?
 In which data file is it?

 Thanks for each help :-)


-- 
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 email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.


[h2] Re: Exception when opening DB after forced shutdown (1.3.176)

2014-05-27 Thread too
Even though I can reproduce this with our app I fail to create separate 
test case to reproduce the problem (i.e. to break the DB). What I can do is 
send you database that H2 fails to open. Perhaps it is not really bug 
during close but not robust enough recovery during startup. Zipped DB has 
10MB and I can share it for you privately if you think that can help

thanks
Tono

On Thursday, May 22, 2014 5:47:11 PM UTC+2, too wrote:

 I have experimented with this a little and here are few notes

- lock file remains in place - this is consistent with shutdown hooks 
not being executed during JVM abort
- size of DB file remains intact during runtime but during process 
termination the size rises by approximately 50MB - which contradicts 
previous point and it seems there is something executed during abort
- I can replicate problem with 100% success rate using our app but I 
fail to create test app to replicate the problem (still have a few ideas 
 to 
try)
- I can replicate the problem with older 1.3.x releases as well as 
with latest 1.4.x release (with MV_STORE=FALSE)
- even though I do not think that there are transactions in progress 
at the time of termination it is possible there are open cursors or 
something similar - read-related

 I can avoid this problem by running H2 in server mode but that is not what 
 I want. 

 Tono

 On Tuesday, May 20, 2014 3:16:03 PM UTC+2, too wrote:

 Hi,
 Sometimes when our application is shut down forcibly it is unable to 
 start again with exceptions below. It does not appear that transaction is 
 in progress at the time of shutdown but I can not be sure. I was unable to 
 create test case but our application reproduces this quite consistently 
 (it's very rare that it starts after being terminated). 
 I have attached debug trace file for failed start - not for the shutdown. 
 I tried INFO logging for shutdown (breaking the db) but nothing seemed 
 interesting there, just bunch of selects. Also no error is logged during 
 shutdown or startup.

 Environment details are

- H2 - 1.3.176
- Java Runtime - Java(TM) SE Runtime Environment (1.7.0_17-b02, 
32b) on Java HotSpot(TM) Client VM (23.7-b01, mixed mode)
- Operating System - Windows 7 (64b, Service Pack 1, version 6.1) 
- connection URL - jdbc:h2:./dbfile;IFEXISTS=TRUE


 NullPointerException - this is what usually happens

 org.h2.jdbc.JdbcSQLException: General error: 
 java.lang.NullPointerException [5-176]
 at org.h2.message.DbException.getJdbcSQLException(DbException.java:344) 
 ~[h2.jar:1.3.176]
 at org.h2.message.DbException.get(DbException.java:167) ~[h2.jar:1.3.176]
 at org.h2.message.DbException.convert(DbException.java:294) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Database.openDatabase(Database.java:291) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Database.init(Database.java:254) ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.openSession(Engine.java:57) ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.openSession(Engine.java:164) ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.createSessionAndValidate(Engine.java:142) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.createSession(Engine.java:125) ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.createSession(Engine.java:27) ~[h2.jar:1.3.176]
 at 
 org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:331) 
 ~[h2.jar:1.3.176]
 at org.h2.jdbc.JdbcConnection.init(JdbcConnection.java:107) 
 ~[h2.jar:1.3.176]
 at org.h2.jdbc.JdbcConnection.init(JdbcConnection.java:91) 
 ~[h2.jar:1.3.176]
 at org.h2.Driver.connect(Driver.java:74) ~[h2.jar:1.3.176]
 at java.sql.DriverManager.getConnection(DriverManager.java:579) 
 ~[na:1.7.0_17]
 at java.sql.DriverManager.getConnection(DriverManager.java:221) 
 ~[na:1.7.0_17]
 at ...
 ... 12 common frames omitted
 Caused by: java.lang.NullPointerException: null
 at org.h2.store.PageStore.removeMeta(PageStore.java:1642) 
 ~[h2.jar:1.3.176]
 at org.h2.store.PageStore.redo(PageStore.java:1565) ~[h2.jar:1.3.176]
 at org.h2.store.PageStore.redoDelete(PageStore.java:1550) 
 ~[h2.jar:1.3.176]
 at org.h2.store.PageLog.recover(PageLog.java:347) ~[h2.jar:1.3.176]
 at org.h2.store.PageStore.recover(PageStore.java:1407) ~[h2.jar:1.3.176]
 at org.h2.store.PageStore.openExisting(PageStore.java:368) 
 ~[h2.jar:1.3.176]
 at org.h2.store.PageStore.open(PageStore.java:289) ~[h2.jar:1.3.176]
 at org.h2.engine.Database.getPageStore(Database.java:2366) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Database.open(Database.java:657) ~[h2.jar:1.3.176]
 at org.h2.engine.Database.openDatabase(Database.java:260) 
 ~[h2.jar:1.3.176]
 ... 25 common frames omitted


 ArrayIndexOutOfBoundsException - I got this one only once

 Caused by: org.h2.jdbc.JdbcSQLException: General error: 
 java.lang.ArrayIndexOutOfBoundsException: 44 [5-176]
 at 
 org.h2.message.DbException.getJdbcSQLException(DbException.java:344) 
 ~[h2.jar:1.3.176]
 at org.h2.message.DbException.get(DbException.java:167

[h2] Re: Exception when opening DB after forced shutdown (1.3.176)

2014-05-22 Thread too
I have experimented with this a little and here are few notes

   - lock file remains in place - this is consistent with shutdown hooks 
   not being executed during JVM abort
   - size of DB file remains intact during runtime but during process 
   termination the size rises by approximately 50MB - which contradicts 
   previous point and it seems there is something executed during abort
   - I can replicate problem with 100% success rate using our app but I 
   fail to create test app to replicate the problem (still have a few ideas to 
   try)
   - I can replicate the problem with older 1.3.x releases as well as with 
   latest 1.4.x release (with MV_STORE=FALSE)
   - even though I do not think that there are transactions in progress at 
   the time of termination it is possible there are open cursors or something 
   similar - read-related

I can avoid this problem by running H2 in server mode but that is not what 
I want. 

Tono

On Tuesday, May 20, 2014 3:16:03 PM UTC+2, too wrote:

 Hi,
 Sometimes when our application is shut down forcibly it is unable to start 
 again with exceptions below. It does not appear that transaction is in 
 progress at the time of shutdown but I can not be sure. I was unable to 
 create test case but our application reproduces this quite consistently 
 (it's very rare that it starts after being terminated). 
 I have attached debug trace file for failed start - not for the shutdown. 
 I tried INFO logging for shutdown (breaking the db) but nothing seemed 
 interesting there, just bunch of selects. Also no error is logged during 
 shutdown or startup.

 Environment details are

- H2 - 1.3.176
- Java Runtime - Java(TM) SE Runtime Environment (1.7.0_17-b02, 
32b) on Java HotSpot(TM) Client VM (23.7-b01, mixed mode)
- Operating System - Windows 7 (64b, Service Pack 1, version 6.1) 
- connection URL - jdbc:h2:./dbfile;IFEXISTS=TRUE


 NullPointerException - this is what usually happens

 org.h2.jdbc.JdbcSQLException: General error: 
 java.lang.NullPointerException [5-176]
 at org.h2.message.DbException.getJdbcSQLException(DbException.java:344) 
 ~[h2.jar:1.3.176]
 at org.h2.message.DbException.get(DbException.java:167) ~[h2.jar:1.3.176]
 at org.h2.message.DbException.convert(DbException.java:294) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Database.openDatabase(Database.java:291) ~[h2.jar:1.3.176]
 at org.h2.engine.Database.init(Database.java:254) ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.openSession(Engine.java:57) ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.openSession(Engine.java:164) ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.createSessionAndValidate(Engine.java:142) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.createSession(Engine.java:125) ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.createSession(Engine.java:27) ~[h2.jar:1.3.176]
 at 
 org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:331) 
 ~[h2.jar:1.3.176]
 at org.h2.jdbc.JdbcConnection.init(JdbcConnection.java:107) 
 ~[h2.jar:1.3.176]
 at org.h2.jdbc.JdbcConnection.init(JdbcConnection.java:91) 
 ~[h2.jar:1.3.176]
 at org.h2.Driver.connect(Driver.java:74) ~[h2.jar:1.3.176]
 at java.sql.DriverManager.getConnection(DriverManager.java:579) 
 ~[na:1.7.0_17]
 at java.sql.DriverManager.getConnection(DriverManager.java:221) 
 ~[na:1.7.0_17]
 at ...
 ... 12 common frames omitted
 Caused by: java.lang.NullPointerException: null
 at org.h2.store.PageStore.removeMeta(PageStore.java:1642) ~[h2.jar:1.3.176]
 at org.h2.store.PageStore.redo(PageStore.java:1565) ~[h2.jar:1.3.176]
 at org.h2.store.PageStore.redoDelete(PageStore.java:1550) ~[h2.jar:1.3.176]
 at org.h2.store.PageLog.recover(PageLog.java:347) ~[h2.jar:1.3.176]
 at org.h2.store.PageStore.recover(PageStore.java:1407) ~[h2.jar:1.3.176]
 at org.h2.store.PageStore.openExisting(PageStore.java:368) 
 ~[h2.jar:1.3.176]
 at org.h2.store.PageStore.open(PageStore.java:289) ~[h2.jar:1.3.176]
 at org.h2.engine.Database.getPageStore(Database.java:2366) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Database.open(Database.java:657) ~[h2.jar:1.3.176]
 at org.h2.engine.Database.openDatabase(Database.java:260) ~[h2.jar:1.3.176]
 ... 25 common frames omitted


 ArrayIndexOutOfBoundsException - I got this one only once

 Caused by: org.h2.jdbc.JdbcSQLException: General error: 
 java.lang.ArrayIndexOutOfBoundsException: 44 [5-176]
 at 
 org.h2.message.DbException.getJdbcSQLException(DbException.java:344) 
 ~[h2.jar:1.3.176]
 at org.h2.message.DbException.get(DbException.java:167) 
 ~[h2.jar:1.3.176]
 at org.h2.message.DbException.convert(DbException.java:294) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Database.openDatabase(Database.java:291) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Database.init(Database.java:254) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.openSession(Engine.java:57) 
 ~[h2.jar:1.3.176]
 at org.h2.engine.Engine.openSession(Engine.java:164) 
 ~[h2.jar:1.3.176]
 at org.h2

[h2] Re: Cannot connect to an existing embedded database

2014-05-21 Thread too
hi,
Just few tips

   - what error is in OpenConcerto.trace.db?
   - try to create some table using the console. does that work? error?
   - what happens if you move the DB to location without spaces?
   - have you experimented with permissions to the DB file?

Tono

On Tuesday, May 20, 2014 5:47:15 PM UTC+2, Ospeleo wrote:

 Hi,
 What is wrong in my process ? 
 I need an outside view.
 I've been investigating this error for 12 hours over 3 days, thought it 
 was linked with my software which uses the H2 database (Openconcerto) but 
 it seems it is more H2/environment-related

 I use OSX10.6.8
 java version 1.6.0_65
 h2-1.3.176.jar

 I have a database (10mB) in 
 olivier:~ moi$ cd Library/Application\ Support/OpenConcerto/DBData/
 olivier:DBData moi$ ls -la
 total 19552
 drwxr-xr-x   4 moi  moi   136 19 mai 21:18 .
 drwxr-xr-x  24 moi  moi   816 19 mai 17:56 ..
 -rw-r--r--   1 moi  moi  10004480 19 mai 21:18 OpenConcerto.h2.db
 -rw-r--r--   1 moi  moi  3945 19 mai 17:18 OpenConcerto.trace.db

 I launch the H2 console in embedded mode with the parameters:
 jdbc:h2:file:/Users/moi/Library/Application\ 
 Support/OpenConcerto/DBData/OpenConcerto;IFEXISTS=TRUE
 login and password

 The console seems to succesfully connect to the database (or else it 
 should display an error message, with the option IFEXISTS=TRUE), but: 
 Where are the tables ? Shouldn't there be the tables listed on the left 
 pane?
 What do I need to do to access these tables?
 Thanks


 https://lh3.googleusercontent.com/-oleaDCRp1cM/U3t30O5n70I/AD0/Ha6UpzVquKI/s1600/Capture+d%E2%80%99e%CC%81cran+2014-05-20+a%CC%80+00.21.00.png



-- 
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 email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.


[h2] Re: Cannot connect to an existing embedded database

2014-05-21 Thread too
I have not realized this right away but backward slash is not URI 
replacement for space. it is %20 . The slash is usually used in file paths 
but not in the URI. JDBC connection string is URI hence you need to make 
sure it is valid. Try the %20 perhaps that will work for you. Maybe 
malformed URI caused driver to ignore IFEXISTS and your blank DB got 
created somewhere. try searching the drive or subpaths of your path or by 
filename

Tono

On Wednesday, May 21, 2014 10:55:55 AM UTC+2, Ospeleo wrote:

 Hi,

 The main problem is found. the '\ ' character in the path is not 
 recognized.
 I created a db in ~ and connected to it, create a table, disconnect.
 I move the db in ~/Library and connect to it: the table is displayed.
 I move the db in ~/Library/Application\ Support and connect to it: the 
 table doesn't show.

 Then, I move OpenConcerto.h2.db in ~/Library and connect to it.
 Get the following error message
 Unique index or primary key violation: PRIMARY KEY ON .PAGE_INDEX; 
 SQL statement:
 ALTER TABLE Default.FWK_MODULE_DEP ADD CONSTRAINT 
 Default.FWK_MODULE_DEP_ID_MODULE_fkey FOREIGN KEY(ID_MODULE) REFERENCES 
 Default.FWK_MODULE_METADATA(ID) ON DELETE CASCADE ON UPDATE CASCADE 
 NOCHECK 
 [23505-176]http://192.168.0.153:8082/login.do?jsessionid=77be6b1a68ea3468fb909c2871ce4302#
  23505/23505 

 I'm investigating it and let you know
 Thanks for the hints

 Le mercredi 21 mai 2014 09:48:00 UTC+2, too a écrit :

 hi,
 Just few tips

- what error is in OpenConcerto.trace.db?
- try to create some table using the console. does that work? error?
- what happens if you move the DB to location without spaces?
- have you experimented with permissions to the DB file?

 Tono

 On Tuesday, May 20, 2014 5:47:15 PM UTC+2, Ospeleo wrote:

 Hi,
 What is wrong in my process ? 
 I need an outside view.
 I've been investigating this error for 12 hours over 3 days, thought it 
 was linked with my software which uses the H2 database (Openconcerto) but 
 it seems it is more H2/environment-related

 I use OSX10.6.8
 java version 1.6.0_65
 h2-1.3.176.jar

 I have a database (10mB) in 
 olivier:~ moi$ cd Library/Application\ Support/OpenConcerto/DBData/
 olivier:DBData moi$ ls -la
 total 19552
 drwxr-xr-x   4 moi  moi   136 19 mai 21:18 .
 drwxr-xr-x  24 moi  moi   816 19 mai 17:56 ..
 -rw-r--r--   1 moi  moi  10004480 19 mai 21:18 OpenConcerto.h2.db
 -rw-r--r--   1 moi  moi  3945 19 mai 17:18 OpenConcerto.trace.db

 I launch the H2 console in embedded mode with the parameters:
 jdbc:h2:file:/Users/moi/Library/Application\ 
 Support/OpenConcerto/DBData/OpenConcerto;IFEXISTS=TRUE
 login and password

 The console seems to succesfully connect to the database (or else it 
 should display an error message, with the option IFEXISTS=TRUE), but: 
 Where are the tables ? Shouldn't there be the tables listed on the left 
 pane?
 What do I need to do to access these tables?
 Thanks


 https://lh3.googleusercontent.com/-oleaDCRp1cM/U3t30O5n70I/AD0/Ha6UpzVquKI/s1600/Capture+d%E2%80%99e%CC%81cran+2014-05-20+a%CC%80+00.21.00.png



-- 
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 email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.


Re: [h2] Is there a way to control size of H2 database file?

2014-05-16 Thread too
sorry for not mentioning it right away.. the version is 1.4.177 and URL 
jdbc:h2:./db/test;IFEXISTS=TRUE;LOCK_TIMEOUT=3

On Thursday, May 15, 2014 2:27:49 PM UTC+2, Noel Grandin wrote:

 which version are you using and what does your database URL look like? 



-- 
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 email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.


[h2] Is there a way to control size of H2 database file?

2014-05-15 Thread too
Hello,
I was wondering whether it is possible to force H2 to create smaller DB 
files. I understand this would happen at the cost of performance but 
perhaps the cost would not be that big.
I found SHUTDOWN COMPACT but that is a little too late.. DB already has 
15GB (where SQLAnywhere with exactly the same schema and data is just 
around 700MB). 7z brings the DB file down to 500MB but that takes several 
hours and very long to extract as well...

So the questions I guess are

   - is this size ratio compared to SQLAnywhere expected? I mean the size 
   difference is more than 20:1
   - are there any settings I could use to connect to DB in some compact 
   mode where DML would result in limited growth of DB file? I was thinking 
   that perhaps the process pre-populating the DB would run slower and produce 
   small DB file. The app which uses the DB later on would benefit from H2 
   performance and start with smaller DB file then
   - are there some recommendations as how to insert data to DB to limit DB 
   file growth? I can think of factors like order of data, number of tables in 
   a transaction, commit frequency (after every row vs once in a while). 
   Perhaps there are other?
   - I briefly experimented with SHUTDOWN COMPACT where it failed for me. I 
   will give it a shot again along with the re-build of DB described 
   in http://www.h2database.com/html/features.html#compacting and post my 
   results here later on

thanks
Tono

-- 
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 email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.


Re: [h2] Re: MVMap#searchRoot fails with IndexOutOfBoundsException and leaves DB in inconsistent state

2014-05-12 Thread too
The replication on my end is very random and I do not have application 
which would always fail. I can however test your fix to run the process 
that is failing for me. Several runs should show whether the problem was 
resolved or not

thanks
Tono

On Friday, May 2, 2014 9:27:13 AM UTC+2, Thomas Mueller wrote:

 Hi,

  I suspect there is bug in my application which can cause that single 
 connection is used by multiple threads to execute statements and commit 
 concurrently on that connection.

 That shouldn't be a problem.

 I did find a concurrency problem, but so far I can only reproduce it when 
 using the option multi_threaded in the database URL. So if you find out 
 how to reproduce the problem (if you have a test case that I can run that 
 at least sometimes runs into this situation) then that would be great!

 Regards,
 Thomas



 On Wed, Apr 30, 2014 at 10:47 AM, too ton...@gmail.com javascript:wrote:

 Hi,
 I made further investigation and I can not replicate this in any reliable 
 matter. It happened again though during processing of different type of 
 data. I do not think blobs are involved. Both failures seem to have in 
 common 30+ column count. Application is very generic and it is not possible 
 for me to identify what were other threads storing to DB at the time of 
 failure, All I get is the record that failed. During the second occurrence 
 of index out of bounds it was not followed by subsequent problems and app 
 ran fine for a while and then again failed with index out of bounds later 
 on.
 I suspect there is bug in my application which can cause that single 
 connection is used by multiple threads to execute statements and commit 
 concurrently on that connection. I need to prove that though and I 
 definitely hope that is not the case :)

 thanks
 Tono


 On Friday, April 25, 2014 3:36:33 PM UTC+2, Thomas Mueller wrote:

 Hi,

 Yes, it looks like a concurrency problem. Would it be possible to post 
 or send me a reproducible test case? If not, could you describe what your 
 program is doing (how many tables, does it use transactions, BLOB or CLOB, 
 what is the schema of the table or tables,...)? 

 Regards,
 Thomas


 On Fri, Apr 25, 2014 at 1:52 PM, too ton...@gmail.com wrote:

 I realized I should have perhaps posted the connection string so here 
 it is jdbc:h2:./db/test;IFEXISTS=TRUE;LOCK_TIMEOUT=3
 There is nothing interesting or special about it though

 Tono

 -- 
 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...@googlegroups.com.
 To post to this group, send email to h2-da...@googlegroups.com.

 Visit this group at http://groups.google.com/group/h2-database.
 For more options, visit https://groups.google.com/d/optout.


  -- 
 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...@googlegroups.com javascript:.
 To post to this group, send email to h2-da...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/h2-database.
 For more options, visit https://groups.google.com/d/optout.




-- 
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 email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.


Re: [h2] Re: MVMap#searchRoot fails with IndexOutOfBoundsException and leaves DB in inconsistent state

2014-04-30 Thread too
Hi,
I made further investigation and I can not replicate this in any reliable 
matter. It happened again though during processing of different type of 
data. I do not think blobs are involved. Both failures seem to have in 
common 30+ column count. Application is very generic and it is not possible 
for me to identify what were other threads storing to DB at the time of 
failure, All I get is the record that failed. During the second occurrence 
of index out of bounds it was not followed by subsequent problems and app 
ran fine for a while and then again failed with index out of bounds later 
on.
I suspect there is bug in my application which can cause that single 
connection is used by multiple threads to execute statements and commit 
concurrently on that connection. I need to prove that though and I 
definitely hope that is not the case :)

thanks
Tono

On Friday, April 25, 2014 3:36:33 PM UTC+2, Thomas Mueller wrote:

 Hi,

 Yes, it looks like a concurrency problem. Would it be possible to post or 
 send me a reproducible test case? If not, could you describe what your 
 program is doing (how many tables, does it use transactions, BLOB or CLOB, 
 what is the schema of the table or tables,...)? 

 Regards,
 Thomas


 On Fri, Apr 25, 2014 at 1:52 PM, too ton...@gmail.com javascript:wrote:

 I realized I should have perhaps posted the connection string so here it 
 is jdbc:h2:./db/test;IFEXISTS=TRUE;LOCK_TIMEOUT=3
 There is nothing interesting or special about it though

 Tono

 -- 
 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...@googlegroups.com javascript:.
 To post to this group, send email to h2-da...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/h2-database.
 For more options, visit https://groups.google.com/d/optout.




-- 
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 email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.


[h2] MVMap#searchRoot fails with IndexOutOfBoundsException and leaves DB in inconsistent state

2014-04-25 Thread too
Hello,
I am experimenting with H2 (v1.4.177) a little and ran into following 
errors. 
My guess is that the main problem is the IndexOutOfBoundsException in MVMap 
which I can again only guess to have been caused by some concurrency 
problem. This happened to me only once in 4 runs of the process (few 
threads inserting high volumes of data concurrently). 
Secondary problem might be just incorrect error handling but it appears 
that H2 db was left in inconsistent state and all subsequent DML commands 
failed with Corrupt page count error and later with Transaction is 
closed. According to logs we even reestablished connection to H2 after 
the IndexOutOfBoundsException error which would indicate the page count 
problem got persisted.

Here is the first exception where MVMap#searchRoot failed

org.h2.jdbc.JdbcSQLException: General error: 
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1; SQL statement:
insert into TFT556PROCEDURESTEP (ID_OBJECT, FG_ALLOW_NEG_VALS, FG_ALLOW_TIME, 
NO_EARLST_DT_ALLOW, TXT_EDIT_MASK, TP_FORMAT, DS_STEP, TXT_HELP, 
TXT_INSTRUCTION, NO_LATEST_DT_ALLOW, NO_MAX_DAYS_FUTURE, NO_MAX_DAYS_PAST, 
NO_MAX_VALUE, NO_MIN_VALUE, CD_PARAMETER, CD_PARENT_STEP, NO_PRECISION, 
NO_SEQUENCE, DS_SHORT_TEXT, CD_STEP, TP_STEP, TXT_SUMMARY_FIELD, 
FG_UE_FROM_MOBILE, FG_USE_STEP_CMNT, TXT_USER_EXIT_NAME, CD_PROCEDURE, 
NO_PROCEDURE_VERSION, NO_RECORD_TIMESTAMP, ID_VERSION, ID_PREV_VERSION1, 
ID_PREV_VERSION2, ID_USER, TS_USER, TS_SERVER, FG_OBJ_DELETED, ID_MSG_RCVD, 
IND_SYNC, IND_COMMS_PRIORITY) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 
?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) 
[5-177]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:344)
at org.h2.message.DbException.get(DbException.java:167)
at org.h2.message.DbException.convert(DbException.java:294)
at org.h2.mvstore.db.MVTable.addRow(MVTable.java:615)
at org.h2.command.dml.Insert.insertRows(Insert.java:157)
at org.h2.command.dml.Insert.update(Insert.java:115)
at org.h2.command.CommandContainer.update(CommandContainer.java:79)
at org.h2.command.Command.executeUpdate(Command.java:254)
at org.h2.jdbc.JdbcPreparedStatement.execute(JdbcPreparedStatement.java:199)
...
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at org.h2.mvstore.MVMap.searchRoot(MVMap.java:1091)
at org.h2.mvstore.MVMap.removeUnusedOldVersions(MVMap.java:900)
at org.h2.mvstore.MVMap.newRoot(MVMap.java:681)
at org.h2.mvstore.MVMap.put(MVMap.java:113)
at org.h2.mvstore.db.TransactionStore.log(TransactionStore.java:267)
at 
org.h2.mvstore.db.TransactionStore$Transaction.log(TransactionStore.java:691)
at 
org.h2.mvstore.db.TransactionStore$TransactionMap.trySet(TransactionStore.java:1087)
at 
org.h2.mvstore.db.TransactionStore$TransactionMap.set(TransactionStore.java:1010)
at 
org.h2.mvstore.db.TransactionStore$TransactionMap.put(TransactionStore.java:988)
at org.h2.mvstore.db.MVPrimaryIndex.add(MVPrimaryIndex.java:141)
at org.h2.mvstore.db.MVTable.addRow(MVTable.java:611)
... 13 more

And here is what happened to all subsequent attempts to modify data

org.h2.jdbc.JdbcSQLException: General error: java.lang.IllegalStateException: 
Corrupt page count -232 [1.4.177/3]; SQL statement:
COMMIT [5-177]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:344)
at org.h2.message.DbException.get(DbException.java:167)
at org.h2.message.DbException.convert(DbException.java:294)
at org.h2.command.Command.executeUpdate(Command.java:262)
at org.h2.jdbc.JdbcConnection.commit(JdbcConnection.java:467)
...
... 5 more
Caused by: java.lang.IllegalStateException: Corrupt page count -232 [1.4.177/3]
at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:757)
at org.h2.mvstore.MVStore.applyFreedSpace(MVStore.java:1201)
at org.h2.mvstore.MVStore.storeNow(MVStore.java:970)
at org.h2.mvstore.MVStore.commitAndSave(MVStore.java:893)
at org.h2.mvstore.MVStore.commit(MVStore.java:854)
at 
org.h2.mvstore.db.TransactionStore.endTransaction(TransactionStore.java:452)
at org.h2.mvstore.db.TransactionStore.commit(TransactionStore.java:343)
at 
org.h2.mvstore.db.TransactionStore$Transaction.commit(TransactionStore.java:764)
at org.h2.engine.Session.commit(Session.java:488)
at org.h2.command.dml.TransactionCommand.update(TransactionCommand.java:47)
at org.h2.command.CommandContainer.update(CommandContainer.java:79)
at org.h2.command.Command.executeUpdate(Command.java:254)
... 7 more


thanks
Tono

-- 
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] Re: MVMap#searchRoot fails with IndexOutOfBoundsException and leaves DB in inconsistent state

2014-04-25 Thread too
I realized I should have perhaps posted the connection string so here it 
is jdbc:h2:./db/test;IFEXISTS=TRUE;LOCK_TIMEOUT=3
There is nothing interesting or special about it though

Tono

On Friday, April 25, 2014 10:47:19 AM UTC+2, too wrote:

 Hello,
 I am experimenting with H2 (v1.4.177) a little and ran into following 
 errors. 
 My guess is that the main problem is the IndexOutOfBoundsException 
 in MVMap which I can again only guess to have been caused by some 
 concurrency problem. This happened to me only once in 4 runs of the process 
 (few threads inserting high volumes of data concurrently). 
 Secondary problem might be just incorrect error handling but it appears 
 that H2 db was left in inconsistent state and all subsequent DML commands 
 failed with Corrupt page count error and later with Transaction is 
 closed. According to logs we even reestablished connection to H2 after 
 the IndexOutOfBoundsException error which would indicate the page count 
 problem got persisted.

 Here is the first exception where MVMap#searchRoot failed

 org.h2.jdbc.JdbcSQLException: General error: 
 java.lang.IndexOutOfBoundsException: Index: 1, Size: 1; SQL statement:
 insert into TFT556PROCEDURESTEP (ID_OBJECT, FG_ALLOW_NEG_VALS, FG_ALLOW_TIME, 
 NO_EARLST_DT_ALLOW, TXT_EDIT_MASK, TP_FORMAT, DS_STEP, TXT_HELP, 
 TXT_INSTRUCTION, NO_LATEST_DT_ALLOW, NO_MAX_DAYS_FUTURE, NO_MAX_DAYS_PAST, 
 NO_MAX_VALUE, NO_MIN_VALUE, CD_PARAMETER, CD_PARENT_STEP, NO_PRECISION, 
 NO_SEQUENCE, DS_SHORT_TEXT, CD_STEP, TP_STEP, TXT_SUMMARY_FIELD, 
 FG_UE_FROM_MOBILE, FG_USE_STEP_CMNT, TXT_USER_EXIT_NAME, CD_PROCEDURE, 
 NO_PROCEDURE_VERSION, NO_RECORD_TIMESTAMP, ID_VERSION, ID_PREV_VERSION1, 
 ID_PREV_VERSION2, ID_USER, TS_USER, TS_SERVER, FG_OBJ_DELETED, ID_MSG_RCVD, 
 IND_SYNC, IND_COMMS_PRIORITY) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 
 ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) 
 [5-177]
 at org.h2.message.DbException.getJdbcSQLException(DbException.java:344)
 at org.h2.message.DbException.get(DbException.java:167)
 at org.h2.message.DbException.convert(DbException.java:294)
 at org.h2.mvstore.db.MVTable.addRow(MVTable.java:615)
 at org.h2.command.dml.Insert.insertRows(Insert.java:157)
 at org.h2.command.dml.Insert.update(Insert.java:115)
 at org.h2.command.CommandContainer.update(CommandContainer.java:79)
 at org.h2.command.Command.executeUpdate(Command.java:254)
 at 
 org.h2.jdbc.JdbcPreparedStatement.execute(JdbcPreparedStatement.java:199)
 ...
 at java.lang.Thread.run(Thread.java:662)
 Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
 at java.util.ArrayList.RangeCheck(ArrayList.java:547)
 at java.util.ArrayList.get(ArrayList.java:322)
 at org.h2.mvstore.MVMap.searchRoot(MVMap.java:1091)
 at org.h2.mvstore.MVMap.removeUnusedOldVersions(MVMap.java:900)
 at org.h2.mvstore.MVMap.newRoot(MVMap.java:681)
 at org.h2.mvstore.MVMap.put(MVMap.java:113)
 at org.h2.mvstore.db.TransactionStore.log(TransactionStore.java:267)
 at 
 org.h2.mvstore.db.TransactionStore$Transaction.log(TransactionStore.java:691)
 at 
 org.h2.mvstore.db.TransactionStore$TransactionMap.trySet(TransactionStore.java:1087)
 at 
 org.h2.mvstore.db.TransactionStore$TransactionMap.set(TransactionStore.java:1010)
 at 
 org.h2.mvstore.db.TransactionStore$TransactionMap.put(TransactionStore.java:988)
 at org.h2.mvstore.db.MVPrimaryIndex.add(MVPrimaryIndex.java:141)
 at org.h2.mvstore.db.MVTable.addRow(MVTable.java:611)
 ... 13 more

 And here is what happened to all subsequent attempts to modify data

 org.h2.jdbc.JdbcSQLException: General error: 
 java.lang.IllegalStateException: Corrupt page count -232 [1.4.177/3]; SQL 
 statement:
 COMMIT [5-177]
 at org.h2.message.DbException.getJdbcSQLException(DbException.java:344)
 at org.h2.message.DbException.get(DbException.java:167)
 at org.h2.message.DbException.convert(DbException.java:294)
 at org.h2.command.Command.executeUpdate(Command.java:262)
 at org.h2.jdbc.JdbcConnection.commit(JdbcConnection.java:467)
 ...
 ... 5 more
 Caused by: java.lang.IllegalStateException: Corrupt page count -232 
 [1.4.177/3]
 at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:757)
 at org.h2.mvstore.MVStore.applyFreedSpace(MVStore.java:1201)
 at org.h2.mvstore.MVStore.storeNow(MVStore.java:970)
 at org.h2.mvstore.MVStore.commitAndSave(MVStore.java:893)
 at org.h2.mvstore.MVStore.commit(MVStore.java:854)
 at 
 org.h2.mvstore.db.TransactionStore.endTransaction(TransactionStore.java:452)
 at org.h2.mvstore.db.TransactionStore.commit(TransactionStore.java:343)
 at 
 org.h2.mvstore.db.TransactionStore$Transaction.commit(TransactionStore.java:764)
 at org.h2.engine.Session.commit(Session.java:488)
 at 
 org.h2.command.dml.TransactionCommand.update(TransactionCommand.java:47)
 at org.h2

[h2] Re: MVMap#searchRoot fails with IndexOutOfBoundsException and leaves DB in inconsistent state

2014-04-25 Thread too
I realized I should have perhaps posted the connection string so here it 
is jdbc:h2:./db/test;IFEXISTS=TRUE;LOCK_TIMEOUT=3
There is nothing interesting or special about it though

Tono

-- 
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 email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.