[h2] DEFRAG SHUTDOWN not removing lock?
Hi all, I use H2 version 1.4.188 in embeddded mode (mvstore enabled) and when I execute the statement DEFRAG SHUTDOWN I'm not able to open a new connection anymore. I use a single connection in my application and that gets closed when I execute the shutdown statement. (connection.isClosed() returns true). But when I then I try to open a new connection it tells me the file is locked. Am I missing something here? I believe this used to work a couple of months ago. Has something changed, or do I have to review my code? ;) Caused by: java.lang.IllegalStateException: The file is locked: nio:C:/H2DB.mv.db [1.4.188/7] at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:773) at org.h2.mvstore.FileStore.open(FileStore.java:167) at org.h2.mvstore.MVStore.init(MVStore.java:346) at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2888) at org.h2.mvstore.db.MVTableEngine$Store.open(MVTableEngine.java:154) ... 68 more Caused by: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(Unknown Source) at sun.nio.ch.SharedFileLockTable.add(Unknown Source) at sun.nio.ch.FileChannelImpl.tryLock(Unknown Source) at org.h2.store.fs.FileNio.tryLock(FilePathNio.java:121) at org.h2.mvstore.cache.FilePathCache$FileCache.tryLock(FilePathCache.java:152) at java.nio.channels.FileChannel.tryLock(Unknown Source) at org.h2.mvstore.FileStore.open(FileStore.java:164) ... 71 more -- 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] When to use MV_STORE=FALSE?
Hi all, I read about MVStore on the website, but are there any specific advantages compared to the old storage when using H2 as a pure JDBC database? I use version 1.4.188 and I'm wondering whether or not I should use MV_STORE=FALSE. The database contains several million rows and I use it in embedded mode. It seems that MVStore takes somewhat more disk space. -- 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] Using H2 as an embedded database for CAD/GIS software
Hello, Steve Hruda was working on an interface with JTS as default implementation : https://github.com/shruda/H2-Mirror/tree/AbstractValueGeometry You have API here https://github.com/shruda/H2-Mirror/blob/AbstractValueGeometry/h2/src/main/org/h2/api/IValueGeometryFactory.java I don't know if that was finished. Regards, Nicolas Fortin Le mardi 4 août 2015 07:45:31 UTC+2, Thomas Mueller a écrit : Hi, Sure, the spatial index can be switched to double. Maybe it makes sense to support both, as float uses less space, and maybe it makes sense to be backward compatible. What do other think about this? About not relying on the JTS suite, I'm think we would need your help, for example in the form of a patch. Regards, Thomas -- 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] Database created with H2 1.3 possibly incompatible with H2 1.4 due to h2.storeLocalTime?
My latest findings: I can reproduce (again, sporadically) the problem by exclusively using h2 1.4.188 as follows: 1) set System.setProperty(h2.storeLocalTime, false), start the app, import some data; then 2) restart the app with System.setProperty(h2.storeLocalTime, true) and import some more data. Once the error occurs, the database is in a corrupted state. I've managed to create and save a corrupted database, which is zipped to only 5 MB. The zip file includes a trace.db file. Thomas, let me know if it is useful for you to see this corrupted database. So far I've been doing this with MV_STORE=false. I'll continue posting more info as I narrow down the problem. On Tuesday, 4 August 2015 18:48:06 UTC+2, Steve McLeod wrote: Hi Thomas, The database is created with 1.3.176. The error happens in 1.4.188. I don't normally set h2.storeLocalTime - I just observed that it has a different default in 1.4 to 1.3, and at one point my investigations led me to code dependent on the value. To investigate further, I tried reloading the database created in 1.3.176, this time running System.setProperty(h2.storeLocalTime, true) immediately before loading the H2 JDBC driver (which I do using Class.forName(org.h2.Driver)), and was able to sporadically reproduce the problem. Here's a stack trace (right now it is happening with a simple INSERT statement) sql = INSERT INTO hand (gameid, casinoid, gamenumber, starttime) VALUES (?, ?, ?, ?) org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException; SQL statement: INSERT INTO hand (gameid, casinoid, gamenumber, starttime) VALUES (?, ?, ?, ?) [5-188] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) at org.h2.message.DbException.get(DbException.java:168) at org.h2.message.DbException.convert(DbException.java:295) at org.h2.table.RegularTable.addRow(RegularTable.java:137) at org.h2.command.dml.Insert.insertRows(Insert.java:156) at org.h2.command.dml.Insert.update(Insert.java:114) at org.h2.command.CommandContainer.update(CommandContainer.java:78) at org.h2.command.Command.executeUpdate(Command.java:254) at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:157) at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:143) at // non-h2 removed Caused by: java.lang.ArrayIndexOutOfBoundsException I'll keep investigating... I can also supply a database that has the problem, but it is 768 MB after zipping...so I think I'll try to write some repro code instead. On Tuesday, 4 August 2015 18:01:59 UTC+2, Thomas Mueller wrote: Hi, Maybe you can reproduce the problem more easily if you set the system property h2.check2 to true. I couldn't reproduce the problem so far, and the code looks correct to me (I debugged it and added some trace output, both for storeLocalTime true and false). Maybe it's a bug in an old version, or some strange combination. Could you post the exact stack trace including error message and error code? Which version of H2 do you use exactly (1.3.x and 1.4.x), and what is the create_build in the database file (select * from information_schema.settings)? How do you set the system property (in which version of H2, how, and when)? It would need to be set before loading the H2 driver. Regards, Thomas On Tuesday, August 4, 2015, Steve McLeod steve@gmail.com wrote: After some more investigation, I think this happens when the database was created with H2 1.3.x, it is opened with H2 1.4.x, a SELECT query is performed that exceeds the maxmemoryrows value (a default of 10,000 rows), and their is a TIMESTAMP column in the result. It seems that the ResultDiskBuffer created to buffer the org.h2.result.ResultSet is getting a wrong result for row length from org.h2.store.Data.getValueLen(Value v, DataHandler handler) when v.getType() is of Value.TIMESTAMP. So a call to ByteArrayOutputStream.checkCapacity is given wrong input. That's what I think, but as the code is foreign to me, I could be very wrong in my analysis. On Monday, 3 August 2015 12:06:35 UTC+2, Steve McLeod wrote: It seems the problem is essentially caused by this: In H2 1.3, h2.storeLocalTime=false In H2 1.4, h2.storeLocalTime=true 1. Create a database with 1.3 that uses columns of type DATETIME 2. Subsequently open it with 1.4 3. You'll get sporadic exceptions when executing SQL select statements. Here's a stack trace: org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException: 2048 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
Re: [h2] Database created with H2 1.3 possibly incompatible with H2 1.4 due to h2.storeLocalTime?
More info: I've been unable to reproduce this using the MVStore. I can make this problem happen when I only use h2 1.3.176 and I can make it happen when I only use h2 1.4.188. I initially create the database and load some data with h2.storeLocalTime=false, then restart the app with h2.storeLocalTime=true and load some more data. Usually database corruption ensues. I've stripped almost every config option from the database url so that it just reads: jdbc:h2:/Users/steve/Library/Application Support/com.barbarysoftware.pokercopilot/database/pokercopilot;MV_STORE=false I believe this confirms it is not a new issue, but it has become apparent now because the default value of h2.storeLocalTime changes from 1.3 to 1.4, and I'm trying to move our app from 1.3 to 1.4. Here's the most recent stack trace: org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException: 2048 [5-176] 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.table.RegularTable.addRow(RegularTable.java:138) at org.h2.engine.UndoLogRecord.undo(UndoLogRecord.java:111) at org.h2.engine.Session.rollbackTo(Session.java:595) at org.h2.command.Command.executeUpdate(Command.java:278) at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:158) at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:144) at com.barbarysoftware.databaseframework.JdbcTemplateCore.update(JdbcTemplateCore.java:311) ... 15 more Caused by: java.lang.ArrayIndexOutOfBoundsException: 2048 at org.h2.store.Data.writeByte(Data.java:379) at org.h2.store.Data.writeValue(Data.java:441) at org.h2.index.PageBtreeIndex.writeRow(PageBtreeIndex.java:394) at org.h2.index.PageBtreeNode.writeData(PageBtreeNode.java:454) at org.h2.index.PageBtreeNode.write(PageBtreeNode.java:427) at org.h2.store.PageStore.writeBack(PageStore.java:1047) at org.h2.util.CacheLRU.removeOld(CacheLRU.java:216) at org.h2.util.CacheLRU.removeOldIfRequired(CacheLRU.java:142) at org.h2.util.CacheLRU.put(CacheLRU.java:116) at org.h2.util.CacheLRU.update(CacheLRU.java:123) at org.h2.store.PageStore.update(PageStore.java:1097) at org.h2.index.PageDataLeaf.addRowTry(PageDataLeaf.java:209) at org.h2.index.PageDataLeaf.split(PageDataLeaf.java:377) at org.h2.index.PageDataNode.addRowTry(PageDataNode.java:139) at org.h2.index.PageDataIndex.addTry(PageDataIndex.java:174) at org.h2.index.PageDataIndex.add(PageDataIndex.java:137) at org.h2.table.RegularTable.addRow(RegularTable.java:120) ... 21 more On Wednesday, 5 August 2015 11:18:36 UTC+2, Steve McLeod wrote: My latest findings: I can reproduce (again, sporadically) the problem by exclusively using h2 1.4.188 as follows: 1) set System.setProperty(h2.storeLocalTime, false), start the app, import some data; then 2) restart the app with System.setProperty(h2.storeLocalTime, true) and import some more data. Once the error occurs, the database is in a corrupted state. I've managed to create and save a corrupted database, which is zipped to only 5 MB. The zip file includes a trace.db file. Thomas, let me know if it is useful for you to see this corrupted database. So far I've been doing this with MV_STORE=false. I'll continue posting more info as I narrow down the problem. On Tuesday, 4 August 2015 18:48:06 UTC+2, Steve McLeod wrote: Hi Thomas, The database is created with 1.3.176. The error happens in 1.4.188. I don't normally set h2.storeLocalTime - I just observed that it has a different default in 1.4 to 1.3, and at one point my investigations led me to code dependent on the value. To investigate further, I tried reloading the database created in 1.3.176, this time running System.setProperty(h2.storeLocalTime, true) immediately before loading the H2 JDBC driver (which I do using Class.forName(org.h2.Driver)), and was able to sporadically reproduce the problem. Here's a stack trace (right now it is happening with a simple INSERT statement) sql = INSERT INTO hand (gameid, casinoid, gamenumber, starttime) VALUES (?, ?, ?, ?) org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException; SQL statement: INSERT INTO hand (gameid, casinoid, gamenumber, starttime) VALUES (?, ?, ?, ?) [5-188] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) at org.h2.message.DbException.get(DbException.java:168) at org.h2.message.DbException.convert(DbException.java:295) at org.h2.table.RegularTable.addRow(RegularTable.java:137) at org.h2.command.dml.Insert.insertRows(Insert.java:156) at org.h2.command.dml.Insert.update(Insert.java:114) at org.h2.command.CommandContainer.update(CommandContainer.java:78) at org.h2.command.Command.executeUpdate(Command.java:254) at
Re: [h2] Database created with H2 1.3 possibly incompatible with H2 1.4 due to h2.storeLocalTime?
Here's a stack trace in the same scenario from h2 1.4.188 org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException: 4096; SQL statement: ROLLBACK [5-188] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) at org.h2.message.DbException.get(DbException.java:168) at org.h2.message.DbException.convert(DbException.java:295) at org.h2.command.Command.executeUpdate(Command.java:262) at org.h2.jdbc.JdbcConnection.rollbackInternal(JdbcConnection.java:1500) at org.h2.jdbc.JdbcConnection.rollback(JdbcConnection.java:488) at org.h2.jdbcx.JdbcXAConnection$PooledJdbcConnection.close(JdbcXAConnection.java:465) at com.barbarysoftware.databaseframework.JdbcTemplateCore.update(JdbcTemplateCore.java:278) ... Caused by: java.lang.ArrayIndexOutOfBoundsException: 4096 at org.h2.store.Data.writeVarLong(Data.java:1254) at org.h2.store.Data.writeValue(Data.java:523) at org.h2.index.PageBtreeIndex.writeRow(PageBtreeIndex.java:393) at org.h2.index.PageBtreeNode.writeData(PageBtreeNode.java:453) at org.h2.index.PageBtreeNode.write(PageBtreeNode.java:426) at org.h2.store.PageStore.writeBack(PageStore.java:1046) at org.h2.store.PageStore.writeBack(PageStore.java:418) at org.h2.store.PageStore.checkpoint(PageStore.java:436) at org.h2.store.PageStore.commit(PageStore.java:1480) at org.h2.engine.Database.commit(Database.java:1995) at org.h2.engine.Session.rollback(Session.java:614) at org.h2.command.dml.TransactionCommand.update(TransactionCommand.java:49) at org.h2.command.CommandContainer.update(CommandContainer.java:78) at org.h2.command.Command.executeUpdate(Command.java:254) ... 17 more On Wednesday, 5 August 2015 13:08:37 UTC+2, Steve McLeod wrote: More info: I've been unable to reproduce this using the MVStore. I can make this problem happen when I only use h2 1.3.176 and I can make it happen when I only use h2 1.4.188. I initially create the database and load some data with h2.storeLocalTime=false, then restart the app with h2.storeLocalTime=true and load some more data. Usually database corruption ensues. I've stripped almost every config option from the database url so that it just reads: jdbc:h2:/Users/steve/Library/Application Support/com.barbarysoftware.pokercopilot/database/pokercopilot;MV_STORE=false I believe this confirms it is not a new issue, but it has become apparent now because the default value of h2.storeLocalTime changes from 1.3 to 1.4, and I'm trying to move our app from 1.3 to 1.4. Here's the most recent stack trace: org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException: 2048 [5-176] 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.table.RegularTable.addRow(RegularTable.java:138) at org.h2.engine.UndoLogRecord.undo(UndoLogRecord.java:111) at org.h2.engine.Session.rollbackTo(Session.java:595) at org.h2.command.Command.executeUpdate(Command.java:278) at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:158) at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:144) at com.barbarysoftware.databaseframework.JdbcTemplateCore.update(JdbcTemplateCore.java:311) ... 15 more Caused by: java.lang.ArrayIndexOutOfBoundsException: 2048 at org.h2.store.Data.writeByte(Data.java:379) at org.h2.store.Data.writeValue(Data.java:441) at org.h2.index.PageBtreeIndex.writeRow(PageBtreeIndex.java:394) at org.h2.index.PageBtreeNode.writeData(PageBtreeNode.java:454) at org.h2.index.PageBtreeNode.write(PageBtreeNode.java:427) at org.h2.store.PageStore.writeBack(PageStore.java:1047) at org.h2.util.CacheLRU.removeOld(CacheLRU.java:216) at org.h2.util.CacheLRU.removeOldIfRequired(CacheLRU.java:142) at org.h2.util.CacheLRU.put(CacheLRU.java:116) at org.h2.util.CacheLRU.update(CacheLRU.java:123) at org.h2.store.PageStore.update(PageStore.java:1097) at org.h2.index.PageDataLeaf.addRowTry(PageDataLeaf.java:209) at org.h2.index.PageDataLeaf.split(PageDataLeaf.java:377) at org.h2.index.PageDataNode.addRowTry(PageDataNode.java:139) at org.h2.index.PageDataIndex.addTry(PageDataIndex.java:174) at org.h2.index.PageDataIndex.add(PageDataIndex.java:137) at org.h2.table.RegularTable.addRow(RegularTable.java:120) ... 21 more On Wednesday, 5 August 2015 11:18:36 UTC+2, Steve McLeod wrote: My latest findings: I can reproduce (again, sporadically) the problem by exclusively using h2 1.4.188 as follows: 1) set System.setProperty(h2.storeLocalTime, false), start the app, import some data; then 2) restart the app with System.setProperty(h2.storeLocalTime, true) and import some more data. Once the error occurs, the database is in a corrupted state. I've managed to create and save a corrupted database, which is zipped to only 5 MB. The zip file includes a trace.db file.
Re: [h2] QUERY_CACHE_SIZE default value too low?
Is it possible you could share a couple of the queries that are taking this long? Perhaps privately with Thomas and myself? On 2015-08-05 02:34 PM, Steve McLeod wrote: I've attached some screenshots from Java VisualVM CPU sampling. -- 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] QUERY_CACHE_SIZE default value too low?
Noel, I've sent a comprehensive list of queries to you privately. The three most-executed queries are: select lastseen from player where playerid=? insert into TournamentPlayerHand (gameid, playerid, playername, seatnumber, stakelevelid, positionid, tournamentid, buyin, entries, casinoid, gametypeid, tableid, tablename, dayid, isplaymoney, iszoompoker, isHero, startTime, tableSize, takeInCents, showdowntakeInCents, nonshowdowntakeInCents, takeInBigBlinds, downcard1, downcard2, downcard3, downcard4, flop1, flop2, flop3, turn, river, handTypeId, numPlayersSittingIn, allInStreetId, equityPercentage, equityValueDiffInCents, rakePaid, timesseen, flopseen, vpip, preflopraised, unopenedpreflopraised, unopenedpreflopraisedopportunity, postflopbet, postflopraised, postflopcalled, postflopfolded, postFlopCallFoldBetOrRaise, postflopbetorraised, blindStealAttempt, blindStealAttemptOpportunity, checkRaised, checkRaisedOpportunity, wentToShowdown, wonAtShowdown, wonWithoutShowdown, threeBetPreflop, threeBetPreflopOpportunity, blindStealDefenseOpportunityOnBigBlind, calledPreflopRaise, calledPreflopRaiseOpportunity, continuationBet_flop, continuationBetOpportunity_flop, continuationBetTurn, continuationBetTurnOpportunity, foldedToBlindStealOnBigBlind, foldedToContinuationBet, foldedToContinuationBetOpportunity, foldedToContinuationBetOnTurn, foldedToContinuationBetOnTurnOpportunity, foldedToPreflopThreeBet, foldedToPreflopThreeBetOpportunity, fourBetPreflop, fourBetPreflopOpportunity, foldedToPreflopFourBet, foldedToPreflopFourBetOpportunity, timesseen_bb, timesseen_sb, timesseen_btn, timesseen_co, timesseen_mp, timesseen_ep, vpip_bb, vpip_sb, vpip_btn, vpip_co, vpip_mp, vpip_ep, pfr_bb, pfr_sb, pfr_sb_btn, pfr_co, pfr_mp, pfr_ep, uopfr_bb, uopfr_sb, uopfr_btn, uopfr_co, uopfr_mp, uopfr_ep, uopfr_opportunity_bb, uopfr_opportunity_sb, uopfr_opportunity_btn, uopfr_opportunity_co, uopfr_opportunity_mp, uopfr_opportunity_ep, betorraisedflop, betorraisedturn, betorraisedriver, flopCallFoldBetOrRaise, turnCallFoldBetOrRaise, riverFlopCallFoldBetOrRaise, donkbet_flop, donkbet_flop_opportunity, donkbet_turn, donkbet_turn_opportunity, donkbet_river, donkbet_river_opportunity, squeezeBetPreflop, squeezeBetPreflopOpportunity, threebet_bb, threebet_sb, threebet_btn, threebet_co, threebet_mp, threebet_ep, threebet_opportunity_bb, threebet_opportunity_sb, threebet_opportunity_btn, threebet_opportunity_co, threebet_opportunity_mp, threebet_opportunity_ep, fourbet_bb, fourbet_sb, fourbet_btn, fourbet_co, fourbet_mp, fourbet_ep, fourbet_opportunity_bb, fourbet_opportunity_sb, fourbet_opportunity_btn, fourbet_opportunity_co, fourbet_opportunity_mp, fourbet_opportunity_ep, checkRaisedFlop, checkRaisedFlopOpportunity, checkRaisedTurn, checkRaisedTurnOpportunity, checkRaisedRiver, checkRaisedRiverOpportunity) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? , ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) update TournamentPlayerTableSizeSummary set lastSeen=?, takeincents=?, showdowntakeInCents=?, nonshowdowntakeInCents=?, takeinbigblinds=?, rakePaid=?, timesseen=?, flopseen=?, vpip=?, preflopraised=?, unopenedpreflopraised=?, unopenedpreflopraisedopportunity=?, postflopbet=?, postflopraised=?, postflopcalled=?, postflopfolded=?, postFlopCallFoldBetOrRaise=?, postflopbetorraised=?, blindStealAttempt=?, blindStealAttemptOpportunity=?, checkRaised=?, checkRaisedOpportunity=?, wentToShowdown=?, wonAtShowdown=?, wonWithoutShowdown=?, threeBetPreflop=?, threeBetPreflopOpportunity=?, blindStealDefenseOpportunityOnBigBlind=?, calledPreflopRaise=?, calledPreflopRaiseOpportunity=?, continuationBet_flop=?, continuationBetOpportunity_flop=?, continuationBetTurn=?, continuationBetTurnOpportunity=?, foldedToBlindStealOnBigBlind=?, foldedToContinuationBet=?, foldedToContinuationBetOpportunity=?, foldedToContinuationBetOnTurn=?, foldedToContinuationBetOnTurnOpportunity=?, foldedToPreflopThreeBet=?, foldedToPreflopThreeBetOpportunity=?, fourBetPreflop=?, fourBetPreflopOpportunity=?, foldedToPreflopFourBet=?, foldedToPreflopFourBetOpportunity=?, timesseen_bb=?, timesseen_sb=?, timesseen_btn=?, timesseen_co=?, timesseen_mp=?, timesseen_ep=?, vpip_bb=?, vpip_sb=?, vpip_btn=?, vpip_co=?, vpip_mp=?, vpip_ep=?, pfr_bb=?, pfr_sb=?, pfr_sb_btn=?, pfr_co=?, pfr_mp=?, pfr_ep=?, uopfr_bb=?, uopfr_sb=?, uopfr_btn=?, uopfr_co=?, uopfr_mp=?, uopfr_ep=?, uopfr_opportunity_bb=?, uopfr_opportunity_sb=?, uopfr_opportunity_btn=?, uopfr_opportunity_co=?, uopfr_opportunity_mp=?, uopfr_opportunity_ep=?, betorraisedflop=?, betorraisedturn=?,
Re: [h2] QUERY_CACHE_SIZE default value too low?
Thanks, I'll have a look tomorrow at them in detail. Tell me, how often is JdbcConnection@preparedStatement called compared to how many times you execute a query? If it's every time, it means that your PreparedStatement caching is not working, which would indicate a problem with your connection pool, or something similar. -- 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] QUERY_CACHE_SIZE default value too low?
Hi Noel, I've actually solved this problem of PreparedStatement caching for my app by increasing QUERY_CACHE_SIZE to 100. But I'm interested in helping solve the bigger issue of why it seems to take a comparatively significant time to create a PreparedStatement. Cheers, Steve On Wednesday, 5 August 2015 16:04:46 UTC+2, Noel Grandin wrote: Thanks, I'll have a look tomorrow at them in detail. Tell me, how often is JdbcConnection@preparedStatement called compared to how many times you execute a query? If it's every time, it means that your PreparedStatement caching is not working, which would indicate a problem with your connection pool, or something similar. -- 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] Database created with H2 1.3 possibly incompatible with H2 1.4 due to h2.storeLocalTime?
Hi, I can reproduce the problem now, and I think I know what the problem is. I hope to have a fix ready in a few days. Regards, Thomas On Wednesday, August 5, 2015, Steve McLeod steve.mcl...@gmail.com wrote: Here's a stack trace in the same scenario from h2 1.4.188 org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException: 4096; SQL statement: ROLLBACK [5-188] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) at org.h2.message.DbException.get(DbException.java:168) at org.h2.message.DbException.convert(DbException.java:295) at org.h2.command.Command.executeUpdate(Command.java:262) at org.h2.jdbc.JdbcConnection.rollbackInternal(JdbcConnection.java:1500) at org.h2.jdbc.JdbcConnection.rollback(JdbcConnection.java:488) at org.h2.jdbcx.JdbcXAConnection$PooledJdbcConnection.close(JdbcXAConnection.java:465) at com.barbarysoftware.databaseframework.JdbcTemplateCore.update(JdbcTemplateCore.java:278) ... Caused by: java.lang.ArrayIndexOutOfBoundsException: 4096 at org.h2.store.Data.writeVarLong(Data.java:1254) at org.h2.store.Data.writeValue(Data.java:523) at org.h2.index.PageBtreeIndex.writeRow(PageBtreeIndex.java:393) at org.h2.index.PageBtreeNode.writeData(PageBtreeNode.java:453) at org.h2.index.PageBtreeNode.write(PageBtreeNode.java:426) at org.h2.store.PageStore.writeBack(PageStore.java:1046) at org.h2.store.PageStore.writeBack(PageStore.java:418) at org.h2.store.PageStore.checkpoint(PageStore.java:436) at org.h2.store.PageStore.commit(PageStore.java:1480) at org.h2.engine.Database.commit(Database.java:1995) at org.h2.engine.Session.rollback(Session.java:614) at org.h2.command.dml.TransactionCommand.update(TransactionCommand.java:49) at org.h2.command.CommandContainer.update(CommandContainer.java:78) at org.h2.command.Command.executeUpdate(Command.java:254) ... 17 more On Wednesday, 5 August 2015 13:08:37 UTC+2, Steve McLeod wrote: More info: I've been unable to reproduce this using the MVStore. I can make this problem happen when I only use h2 1.3.176 and I can make it happen when I only use h2 1.4.188. I initially create the database and load some data with h2.storeLocalTime=false, then restart the app with h2.storeLocalTime=true and load some more data. Usually database corruption ensues. I've stripped almost every config option from the database url so that it just reads: jdbc:h2:/Users/steve/Library/Application Support/com.barbarysoftware.pokercopilot/database/pokercopilot;MV_STORE=false I believe this confirms it is not a new issue, but it has become apparent now because the default value of h2.storeLocalTime changes from 1.3 to 1.4, and I'm trying to move our app from 1.3 to 1.4. Here's the most recent stack trace: org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException: 2048 [5-176] 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.table.RegularTable.addRow(RegularTable.java:138) at org.h2.engine.UndoLogRecord.undo(UndoLogRecord.java:111) at org.h2.engine.Session.rollbackTo(Session.java:595) at org.h2.command.Command.executeUpdate(Command.java:278) at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:158) at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:144) at com.barbarysoftware.databaseframework.JdbcTemplateCore.update(JdbcTemplateCore.java:311) ... 15 more Caused by: java.lang.ArrayIndexOutOfBoundsException: 2048 at org.h2.store.Data.writeByte(Data.java:379) at org.h2.store.Data.writeValue(Data.java:441) at org.h2.index.PageBtreeIndex.writeRow(PageBtreeIndex.java:394) at org.h2.index.PageBtreeNode.writeData(PageBtreeNode.java:454) at org.h2.index.PageBtreeNode.write(PageBtreeNode.java:427) at org.h2.store.PageStore.writeBack(PageStore.java:1047) at org.h2.util.CacheLRU.removeOld(CacheLRU.java:216) at org.h2.util.CacheLRU.removeOldIfRequired(CacheLRU.java:142) at org.h2.util.CacheLRU.put(CacheLRU.java:116) at org.h2.util.CacheLRU.update(CacheLRU.java:123) at org.h2.store.PageStore.update(PageStore.java:1097) at org.h2.index.PageDataLeaf.addRowTry(PageDataLeaf.java:209) at org.h2.index.PageDataLeaf.split(PageDataLeaf.java:377) at org.h2.index.PageDataNode.addRowTry(PageDataNode.java:139) at org.h2.index.PageDataIndex.addTry(PageDataIndex.java:174) at org.h2.index.PageDataIndex.add(PageDataIndex.java:137) at org.h2.table.RegularTable.addRow(RegularTable.java:120) ... 21 more On Wednesday, 5 August 2015 11:18:36 UTC+2, Steve McLeod wrote: My latest findings: I can reproduce (again, sporadically) the problem by exclusively using h2 1.4.188 as follows: 1) set System.setProperty(h2.storeLocalTime, false), start the app, import some data; then 2) restart the app with System.setProperty(h2.storeLocalTime,
Re: [h2] Database created with H2 1.3 possibly incompatible with H2 1.4 due to h2.storeLocalTime?
Hi, Steve, thanks a lot for your help! Regards, Thomas On Wednesday, August 5, 2015, Thomas Mueller thomas.tom.muel...@gmail.com wrote: Hi, I can reproduce the problem now, and I think I know what the problem is. I hope to have a fix ready in a few days. Regards, Thomas On Wednesday, August 5, 2015, Steve McLeod steve.mcl...@gmail.com javascript:_e(%7B%7D,'cvml','steve.mcl...@gmail.com'); wrote: Here's a stack trace in the same scenario from h2 1.4.188 org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException: 4096; SQL statement: ROLLBACK [5-188] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) at org.h2.message.DbException.get(DbException.java:168) at org.h2.message.DbException.convert(DbException.java:295) at org.h2.command.Command.executeUpdate(Command.java:262) at org.h2.jdbc.JdbcConnection.rollbackInternal(JdbcConnection.java:1500) at org.h2.jdbc.JdbcConnection.rollback(JdbcConnection.java:488) at org.h2.jdbcx.JdbcXAConnection$PooledJdbcConnection.close(JdbcXAConnection.java:465) at com.barbarysoftware.databaseframework.JdbcTemplateCore.update(JdbcTemplateCore.java:278) ... Caused by: java.lang.ArrayIndexOutOfBoundsException: 4096 at org.h2.store.Data.writeVarLong(Data.java:1254) at org.h2.store.Data.writeValue(Data.java:523) at org.h2.index.PageBtreeIndex.writeRow(PageBtreeIndex.java:393) at org.h2.index.PageBtreeNode.writeData(PageBtreeNode.java:453) at org.h2.index.PageBtreeNode.write(PageBtreeNode.java:426) at org.h2.store.PageStore.writeBack(PageStore.java:1046) at org.h2.store.PageStore.writeBack(PageStore.java:418) at org.h2.store.PageStore.checkpoint(PageStore.java:436) at org.h2.store.PageStore.commit(PageStore.java:1480) at org.h2.engine.Database.commit(Database.java:1995) at org.h2.engine.Session.rollback(Session.java:614) at org.h2.command.dml.TransactionCommand.update(TransactionCommand.java:49) at org.h2.command.CommandContainer.update(CommandContainer.java:78) at org.h2.command.Command.executeUpdate(Command.java:254) ... 17 more On Wednesday, 5 August 2015 13:08:37 UTC+2, Steve McLeod wrote: More info: I've been unable to reproduce this using the MVStore. I can make this problem happen when I only use h2 1.3.176 and I can make it happen when I only use h2 1.4.188. I initially create the database and load some data with h2.storeLocalTime=false, then restart the app with h2.storeLocalTime=true and load some more data. Usually database corruption ensues. I've stripped almost every config option from the database url so that it just reads: jdbc:h2:/Users/steve/Library/Application Support/com.barbarysoftware.pokercopilot/database/pokercopilot;MV_STORE=false I believe this confirms it is not a new issue, but it has become apparent now because the default value of h2.storeLocalTime changes from 1.3 to 1.4, and I'm trying to move our app from 1.3 to 1.4. Here's the most recent stack trace: org.h2.jdbc.JdbcSQLException: General error: java.lang.ArrayIndexOutOfBoundsException: 2048 [5-176] 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.table.RegularTable.addRow(RegularTable.java:138) at org.h2.engine.UndoLogRecord.undo(UndoLogRecord.java:111) at org.h2.engine.Session.rollbackTo(Session.java:595) at org.h2.command.Command.executeUpdate(Command.java:278) at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:158) at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:144) at com.barbarysoftware.databaseframework.JdbcTemplateCore.update(JdbcTemplateCore.java:311) ... 15 more Caused by: java.lang.ArrayIndexOutOfBoundsException: 2048 at org.h2.store.Data.writeByte(Data.java:379) at org.h2.store.Data.writeValue(Data.java:441) at org.h2.index.PageBtreeIndex.writeRow(PageBtreeIndex.java:394) at org.h2.index.PageBtreeNode.writeData(PageBtreeNode.java:454) at org.h2.index.PageBtreeNode.write(PageBtreeNode.java:427) at org.h2.store.PageStore.writeBack(PageStore.java:1047) at org.h2.util.CacheLRU.removeOld(CacheLRU.java:216) at org.h2.util.CacheLRU.removeOldIfRequired(CacheLRU.java:142) at org.h2.util.CacheLRU.put(CacheLRU.java:116) at org.h2.util.CacheLRU.update(CacheLRU.java:123) at org.h2.store.PageStore.update(PageStore.java:1097) at org.h2.index.PageDataLeaf.addRowTry(PageDataLeaf.java:209) at org.h2.index.PageDataLeaf.split(PageDataLeaf.java:377) at org.h2.index.PageDataNode.addRowTry(PageDataNode.java:139) at org.h2.index.PageDataIndex.addTry(PageDataIndex.java:174) at org.h2.index.PageDataIndex.add(PageDataIndex.java:137) at org.h2.table.RegularTable.addRow(RegularTable.java:120) ... 21 more On Wednesday, 5 August 2015 11:18:36 UTC+2, Steve McLeod wrote: My latest findings: I can reproduce (again, sporadically) the problem
Re: [h2] MVStore with MVCC performance degradation
I had emailed you the trace file, but haven't got a reply, so here it is on Google drive shared to you: https://drive.google.com/open?id=0B7fRq__lUQbCRXJIM2NCVVdpZGM On Thursday, July 30, 2015 at 6:21:12 AM UTC-7, Noel Grandin wrote: On 2015-07-28 06:10 PM, Wes Clark wrote: Link to trace file: https://drive.google.com/open?id=0B7fRq__lUQbCRXJIM2NCVVdpZGM Can't access this. -- 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] QUERY_CACHE_SIZE default value too low?
The thing is, I don't think there is a problem. I think that your code is not caching PreparedStatement 's properly, and the rest of H2 is so fast, that the only thing left in the profile is the parser initialisation :) On Wed, 05 Aug 2015 at 16:27, Steve McLeod steve.mcl...@gmail.com wrote: Hi Noel, I've actually solved this problem of PreparedStatement caching for my app by increasing QUERY_CACHE_SIZE to 100. But I'm interested in helping solve the bigger issue of why it seems to take a comparatively significant time to create a PreparedStatement. Cheers, Steve On Wednesday, 5 August 2015 16:04:46 UTC+2, Noel Grandin wrote: Thanks, I'll have a look tomorrow at them in detail. Tell me, how often is JdbcConnection@preparedStatement called compared to how many times you execute a query? If it's every time, it means that your PreparedStatement caching is not working, which would indicate a problem with your connection pool, or something similar. -- 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+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] INIT in memory jdbc url
Hi, Why does the second connection calls the *INIT* when the database *tes*t is already in memory via the first connection? DriverManager.getConnection(jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;INIT=runscript from 'test/snapshot.sql'); DriverManager.getConnection(jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;INIT=runscript from 'test/snapshot.sql'); I expected the INIT to behave like derby's *createFrom*. What I see is that INIT is called everytime the connection is made. Thanx, --Ivo -- 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] sourceforge has probably still not fully recovered
The problem is most likely sourceforge; they had serious outages recently. The running joke is they were down for a week but hardly anyone noticed :) Cedric Buest blogged recently about uploading to maven central and bintray here: http://beust.com/weblog/2015/07/13/the-long-and-arduous-road-to-jcenter-and-maven-bliss/ -Alex On Tuesday, August 4, 2015 at 2:56:05 PM UTC-4, Thomas Mueller wrote: Hi, I see. I don't know what the problem is, but I have uploaded the Maven files to SourceForge as usual. For some reason outside of my control, they are not synchronized to the Maven repository. I will ask the Maven guys what the problem is. -- 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.
