[jira] Updated: (DERBY-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=all ] Mayuresh Nirhali updated DERBY-418: --- Attachment: derby418_v6.diff Thanks Knut, for catching that! I have attached a new patch with changes suggested by Knut, derby418_v6.diff. > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. >Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > Attachments: AutoCommitTest.java, derby418_v1.diff, derby418_v2.diff, > derby418_v3.diff, derby418_v4.diff, derby418_v5.diff, derby418_v6.diff > > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) >at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) >at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) >at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) >at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) >at vi.hotspot.database.DataInterface._query(DataInterface.java:181) >at vi.hotspot.database.DataInterface.query(DataInterface.java:160) >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > vi.hotspot.exception.ServerTransactionException >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > Derby is running in standalone mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/se
[jira] Updated: (DERBY-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=all ] Mayuresh Nirhali updated DERBY-418: --- Attachment: derby418_v5.diff Thanks Dan for great suggestions. I have integrated your suggestions in this latest patch. Regarding the acts.size() > 20 clause, I think it could still be beneficial. With this clause, we can prevent the overhead of iterating through the entire activation vector everytime an activation is marked unused. Since this is a clean up activity, defering the close of unused activations by some time should not cause extra overhead for every such object. let me know if there is anything I am missing here. This clause is not removed in the latest patch. I have also reindentated the changed code and it should look fine now. > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. >Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > Attachments: AutoCommitTest.java, derby418_v1.diff, derby418_v2.diff, > derby418_v3.diff, derby418_v4.diff, derby418_v5.diff > > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) >at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) >at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) >at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) >at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) >at vi.hotspot.database.DataInterface._query(DataInterface.java:181) >at vi.hotspot.database.DataInterface.query(DataInterface.java:160) >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > vi.hotspot.exception.ServerTransactionExce
[jira] Updated: (DERBY-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=all ] Mayuresh Nirhali updated DERBY-418: --- Attachment: derby418_v4.diff Thanks knut and apologies for missing out on indentation guidelines. I have attached another patch integrating both the comments from Knut. Comments welcome. :) > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. >Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > Attachments: AutoCommitTest.java, derby418_v1.diff, derby418_v2.diff, > derby418_v3.diff, derby418_v4.diff > > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) >at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) >at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) >at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) >at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) >at vi.hotspot.database.DataInterface._query(DataInterface.java:181) >at vi.hotspot.database.DataInterface.query(DataInterface.java:160) >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > vi.hotspot.exception.ServerTransactionException >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > Derby is running in standalone mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.ap
[jira] Updated: (DERBY-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=all ] Mayuresh Nirhali updated DERBY-418: --- Attachment: derby418_v3.diff Thanks Knut for your suggestions. Iterating over Activations vector only when we know that at least one activation is marked unused will save some cycles in case of non-singleUse activations. I have included another flag as you suggested and the patch is attached. The fix also includes detailed comments and exception correction. I have started a derbyall testrun. Let me know if you have any further comments. > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. >Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > Attachments: AutoCommitTest.java, derby418_v1.diff, derby418_v2.diff, > derby418_v3.diff > > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) >at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) >at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) >at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) >at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) >at vi.hotspot.database.DataInterface._query(DataInterface.java:181) >at vi.hotspot.database.DataInterface.query(DataInterface.java:160) >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > vi.hotspot.exception.ServerTransactionException >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java
[jira] Updated: (DERBY-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=all ] Mayuresh Nirhali updated DERBY-418: --- Attachment: derby418_v2.diff posting another version of the patch here. I have corrected the catch block and now throwing the wrapped exception. This change has introduced some method declaration changes as well. Let me know if there are any concerns with this change. Also, the added code block now checks if the acts size is more than 20 before closing the unused activations, this will save some cost of identifying unused activations everytime the addActivation is called. > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. >Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > Attachments: AutoCommitTest.java, derby418_v1.diff, derby418_v2.diff > > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) >at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) >at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) >at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) >at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) >at vi.hotspot.database.DataInterface._query(DataInterface.java:181) >at vi.hotspot.database.DataInterface.query(DataInterface.java:160) >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > vi.hotspot.exception.ServerTransactionException >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(Up
[jira] Updated: (DERBY-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=all ] Mayuresh Nirhali updated DERBY-418: --- Attachment: derby418_v1.diff Thanks Knut, Making BaseActivation.inUse volatile does solve the synchronization problem between the threads. I do not see OOME with the above change along with the fix suggested in previous comments. I have attached a patch now. I shall run derbyall with this change. I would appreciate if someone can take a look at the way the exception is handled in this patch and could point out if there is something that I am missing out. Thanks > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. >Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > Attachments: AutoCommitTest.java, derby418_v1.diff > > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) >at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) >at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) >at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) >at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) >at vi.hotspot.database.DataInterface._query(DataInterface.java:181) >at vi.hotspot.database.DataInterface.query(DataInterface.java:160) >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > vi.hotspot.exception.ServerTransactionException >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >a
[jira] Updated: (DERBY-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=all ] Rick Hillegas updated DERBY-418: Urgency: Normal > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. >Reporter: Sunitha Kambhampati > Fix For: 10.2.0.0 > > Attachments: AutoCommitTest.java > > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) >at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) >at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) >at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) >at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) >at vi.hotspot.database.DataInterface._query(DataInterface.java:181) >at vi.hotspot.database.DataInterface.query(DataInterface.java:160) >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > vi.hotspot.exception.ServerTransactionException >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > Derby is running in standalone mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=all ] Sunitha Kambhampati updated DERBY-418: -- Attachment: AutoCommitTest.java This repro was given by Chris. http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html. To run java -Xmx64M AutoCommitTest > outofmemory error when running large query in autocommit=false mode > --- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Type: Bug > Components: Store > Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. jdk141. > Reporter: Sunitha Kambhampati > Fix For: 10.2.0.0 > Attachments: AutoCommitTest.java > > On the derby-user list, Chris reported tihs problem with his application and > also a repro for the problem. I am logging the jira issue so it doesnt get > lost in all the mail. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > --from chris's post-- > I'm running a set of ~5 queries on one table, using inserts and updates, > and i want to be able to roll them back so i turned off autocommit using > setAutoCommit(false). As the update runs, the memory used by the JVM > increases continually until i get the following exception about 20% of the > way through: > ERROR 40XT0: An internal error was identified by RawStore module. >at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) >at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) >at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) >at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) >at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) >at > org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) >at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) >at > org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) >at > org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) >at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) >at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) >at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) >at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) >at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) >at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) >at vi.hotspot.database.DataInterface._query(DataInterface.java:181) >at vi.hotspot.database.DataInterface.query(DataInterface.java:160) >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > vi.hotspot.exception.ServerTransactionException >at > vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) >at > vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) >at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) >at java.lang.Thread.run(Thread.java:534) > Derby is running in standalone mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
