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 >>>>> 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" [50000-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 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+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.
