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

Reply via email to