I think I have found it. As I suspected it is the large ResultSets that are causing the transaction-log to grow. Today I ran into another problem, which I believe is caused by the same thing.
java.lang.RuntimeException: Undo entry not written at org.h2.message.DbException.throwInternalError(DbException.java:228) at org.h2.store.PageLog.addUndo(PageLog.java:486) at org.h2.store.PageStore.free(PageStore.java:1212) at org.h2.store.PageStore.free(PageStore.java:1195) at org.h2.index.PageDataLeaf.freeRecursive(PageDataLeaf.java:426) at org.h2.index.PageDataNode.freeRecursive(PageDataNode.java:263) at org.h2.index.PageDataNode.freeRecursive(PageDataNode.java:263) at org.h2.index.PageDataIndex.removeAllRows(PageDataIndex.java:379) at org.h2.index.PageDataIndex.truncate(PageDataIndex.java:364) at org.h2.table.RegularTable.truncate(RegularTable.java:388) at org.h2.result.ResultTempTable.dropTable(ResultTempTable.java:149) at org.h2.result.ResultTempTable.close(ResultTempTable.java:139) at org.h2.result.LocalResult.close(LocalResult.java:381) at org.h2.jdbc.JdbcResultSet.nextRow(JdbcResultSet.java:2993) at org.h2.jdbc.JdbcResultSet.next(JdbcResultSet.java:116) ... 15 common frames omitted I have two questions about this: 1. What does this do? log.addUndo(pageId, null); (in PageStore.java:1212) To me it looks like setting the page-parameter to null is what is causing the exception. 2. Wouldn't it be better to just delete the ResultSet-table without undo-support? Is there any use-case when you want to undo the closing of a ResultSet? Regards Carl Hasselskog On Wednesday, April 11, 2012 9:36:27 PM UTC+2, Thomas Mueller wrote: > > Hi, > > Could you use the Recover tool to find out which session (= > connection) was not committed? See at the beginning of the section > "---- Transaction log ----", and look at those sessions that were not > committed. > > Regards, > Thomas > > > On Mon, Apr 9, 2012 at 11:28 AM, Carl Hasselskog <[email protected]> wrote: > > In my application the opening of the first connection is quite slow > (often > >>60s). After profiling it I think it the result of a large undo-log (i.e. > > stage RECOVERY_STAGE_UNDO in recover()). The strange thing is that I am > not > > creating any large transactions (only use auto-commit = true). What is it > > that can cause the undo-log to grow so much if you're not creating any > > transaction yourself? One theory I have is that I have some quite large > > ResultSets that create temporary tables and that are not closed very > often. > > They are usually still open when the application is closed. Can that > cause > > the transaction-log to grow? If so, do you have any tips on how I can > work > > around it? > > > > Thanks! > > Carl Hasselskog > > > > -- > > You received this message because you are subscribed to the Google Groups > > "H2 Database" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/h2-database/-/qI3CjiX4ebsJ. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/h2-database?hl=en. > > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To view this discussion on the web visit https://groups.google.com/d/msg/h2-database/-/Vh1UxXaG_HsJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
